perm filename F88[JNK,JMC] blob
sn#865837 filedate 1988-12-12 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00529 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00082 00002
C00083 00003 ∂10-Jul-88 0242 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #41
C00105 00004 ∂10-Jul-88 0605 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #42
C00158 00005 ∂10-Jul-88 0942 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #43
C00173 00006 ∂11-Jul-88 1443 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #44
C00191 00007 ∂12-Jul-88 0934 @SUMEX-AIM.Stanford.EDU:Acuff@Sumex-AIM.Stanford.EDU [Gregor.pa@Xerox.COM: CLOS Workshop]
C00195 00008 ∂14-Jul-88 1728 AAAI-OFFICE@SUMEX-AIM.Stanford.EDU [AAAI <AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>: Publications Committe Meeting]
C00198 00009 ∂15-Jul-88 0943 HEMENWAY@Score.Stanford.EDU Research Mentor Information Packet
C00201 00010 ∂15-Jul-88 1154 @Score.Stanford.EDU:tom@polya.Stanford.EDU printer news
C00205 00011 ∂15-Jul-88 1503 @Score.Stanford.EDU:rw@polya.Stanford.EDU volunteer needed for orientation brunch
C00208 00012 ∂15-Jul-88 1825 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #28
C00296 00013 ∂15-Jul-88 1831 ullman@polya.Stanford.EDU last two chapters available.
C00298 00014 ∂15-Jul-88 1835 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #29
C00335 00015 ∂15-Jul-88 1913 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #28
C00424 00016 ∂15-Jul-88 2049 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #27
C00512 00017 ∂15-Jul-88 2120 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #46
C00521 00018 ∂15-Jul-88 2143 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #42
C00574 00019 ∂15-Jul-88 2152 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #45
C00580 00020 ∂15-Jul-88 2301 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #44
C00598 00021 ∂16-Jul-88 0117 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #39
C00640 00022 ∂16-Jul-88 0137 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #44
C00658 00023 ∂16-Jul-88 2354 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu French-Israeli Symposium on Combinatorics and Algorithms
C00666 00024 ∂17-Jul-88 0518 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #47
C00684 00025 ∂17-Jul-88 0533 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #48
C00700 00026 ∂18-Jul-88 1320 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #49
C00713 00027 ∂18-Jul-88 2107 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Divide and Conquer
C00718 00028 ∂19-Jul-88 0501 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Urgent: Reply to Cerbone Giuseppe's query
C00720 00029 ∂19-Jul-88 1154 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #51
C00737 00030 ∂19-Jul-88 1429 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Salary Increases
C00739 00031 ∂19-Jul-88 1837 mad@polya.Stanford.EDU transitive closure paper
C00740 00032 ∂19-Jul-88 2213 @Score.Stanford.EDU:HIRSH@SUMEX-AIM.Stanford.EDU CSD Service Award Nominations
C00742 00033 ∂21-Jul-88 1544 MJH-LISPM-mailer Symbolics disk usage
C00744 00034 ∂22-Jul-88 1049 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Thermodynamic Depth
C00748 00035 ∂22-Jul-88 1716 LOGMTC-mailer Martin Davis Talk
C00753 00036 ∂25-Jul-88 1152 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #52
C00768 00037 ∂26-Jul-88 2250 FEIGENBAUM@SUMEX-AIM.Stanford.EDU [seminars@csl.sri.com (contact lunt@csl.sri.com): David Notkin talk at SRI]
C00773 00038 ∂27-Jul-88 0813 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Roommate for PODC 88
C00776 00039 ∂27-Jul-88 1240 @Score.Stanford.EDU:rw@polya.Stanford.EDU orientation brunch (please?)
C00779 00040 ∂28-Jul-88 1718 SHOHAM@Score.Stanford.EDU laptops
C00780 00041 ∂28-Jul-88 1758 SHOHAM@Score.Stanford.EDU laptops
C00781 00042 ∂30-Jul-88 1023 @Score.Stanford.EDU:allison@shasta.stanford.edu Re: laptops
C00782 00043 ∂03-Aug-88 1434 @Score.Stanford.EDU:tajnai@polya.Stanford.EDU Is work being done on "mapping of cognitive load"?
C00785 00044 ∂03-Aug-88 2153 @Score.Stanford.EDU:HIRSH@SUMEX-AIM.Stanford.EDU nominations deadline reminder -- Monday
C00787 00045 ∂04-Aug-88 2033 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu cheap proceedings
C00790 00046 ∂05-Aug-88 1004 DELAGI@SUMEX-AIM.Stanford.EDU [delagi%caldec.DEC@decwrl.dec.com (Bruce Delagi): vision processing]
C00797 00047 ∂05-Aug-88 1141 ingrid@russell.stanford.edu Visiting Scholar cards
C00799 00048 ∂06-Aug-88 1254 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu FIRST ANNUAL MEETING OF THE INTERNATIONAL NEURAL NETWORK SOCIETY
C00805 00049 ∂06-Aug-88 1436 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu spokespeople
C00808 00050 ∂06-Aug-88 1445 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu 1988/89 CSD Committees
C00818 00051 ∂09-Aug-88 1537 TAJNAI@Score.Stanford.EDU A New Milestone for the Computer Forum
C00820 00052 ∂10-Aug-88 0923 STAGER@Score.Stanford.EDU Grade sheets
C00822 00053 ∂10-Aug-88 0936 @Score.Stanford.EDU:littell@polya.Stanford.EDU RAships
C00824 00054 ∂11-Aug-88 1022 TOM@Score.Stanford.EDU
C00826 00055 ∂11-Aug-88 1029 SHOHAM@Score.Stanford.EDU orals
C00828 00056 ∂11-Aug-88 1444 X3J13-mailer CLOS workshop
C00833 00057 ∂11-Aug-88 1518 STAGER@Score.Stanford.EDU CS300
C00835 00058 ∂11-Aug-88 1607 X3J13-mailer CLOS workshop
C00840 00059 ∂11-Aug-88 1644 GILBERTSON@Score.Stanford.EDU [Thea Davis <DAVIS@Score.Stanford.EDU>: Parking Permits]
C00843 00060 ∂11-Aug-88 1655 GILBERTSON@Score.Stanford.EDU [Edith Gilbertson <GILBERTSON@Score.Stanford.EDU>: MJH Carpet Cleaning Reminder]
C00846 00061
C00847 00062 ∂13-Aug-88 1742 hoffman@csli.Stanford.EDU SSP Forum
C00853 00063 ∂14-Aug-88 0910 @Score.Stanford.EDU:WIEDERHOLD@SUMEX-AIM.Stanford.EDU Marriage Announcement
C00855 00064 ∂14-Aug-88 1820 hayes.pa@Xerox.COM Re: rough draft SSP reading list
C00858 00065 ∂14-Aug-88 1820 hayes.pa@Xerox.COM Re: SSP Forum
C00860 00066 ∂15-Aug-88 0904 @polya.Stanford.EDU:ARK@SAIL.Stanford.EDU Adv. Pgm.: Int. Symp. on Parallel and Distrib Systems, Dec 5-7, 88
C00869 00067 ∂15-Aug-88 1729 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu polymorphism versus macroexpansion
C00872 00068 ∂15-Aug-88 1748 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Can someone suggest a good survey articles on Complexity?
C00875 00069 ∂15-Aug-88 1748 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu my left-over proceedings are sold already
C00878 00070 ∂15-Aug-88 1808 LOGMTC-mailer Next LICS
C00884 00071 ∂16-Aug-88 1047 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu TCS geneology
C00889 00072 ∂16-Aug-88 1047 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu LICS '89
C00896 00073 ∂16-Aug-88 1048 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Neural Computation
C00907 00074 ∂16-Aug-88 1048 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Kolmogorov Complexity is not "decidable"
C00920 00075 ∂16-Aug-88 1047 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Problem: zeros of a function
C00925 00076 ∂16-Aug-88 1050 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu cutting bodies with planes
C00929 00077 ∂16-Aug-88 1050 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu 12th Columbia University Theory Day
C00933 00078 ∂16-Aug-88 1050 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Application of Splay Trees to Data Compression
C00938 00079 ∂16-Aug-88 1154 GILBERTSON@Score.Stanford.EDU MJH Carpet Cleaning Tonite
C00940 00080 ∂17-Aug-88 1021 GILBERTSON@Score.Stanford.EDU BLDG 460 CARPET CLEANING *FINISHING*
C00943 00081 ∂17-Aug-88 1134 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu TCS geneology
C00947 00082 ∂17-Aug-88 1344 @polya.Stanford.EDU:ARK@SAIL.Stanford.EDU Adv. Pgm.: Int. Symp. on Parallel and Distrib Systems, Dec 5-7, 88
C00956 00083 ∂18-Aug-88 1150 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Logics in Computer Science Proceedings
C00959 00084 ∂19-Aug-88 1210 X3J13-mailer Virginia and Hawaii X3J13 meetings
C00968 00085 ∂22-Aug-88 0814 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu call for papers -- workshop on database programming languages
C00975 00086 ∂22-Aug-88 0817 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Papers: MFCS'89
C00982 00087 ∂22-Aug-88 1630 DELAGI@SUMEX-AIM.Stanford.EDU [Lori S. Grob <grob@cmcl2.NYU.EDU>:]
C00998 00088 ∂23-Aug-88 1448 JONES@Score.Stanford.EDU Honor Code
C01000 00089 ∂23-Aug-88 2300 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu Re: Honor Code
C01002 00090 ∂24-Aug-88 1202 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu International Symposium on Optimal Algorithms
C01008 00091 ∂26-Aug-88 0923 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Theory Net archives
C01011 00092 ∂26-Aug-88 0932 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Theorynet archives and FTP
C01014 00093 ∂27-Aug-88 0935 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu 10th International Conference on Petri Nets
C01023 00094 ∂28-Aug-88 1228 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU NSF waste
C01026 00095 ∂28-Aug-88 1247 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU Special Initiative on Coordination Theory and Technology
C01031 00096 ∂28-Aug-88 1446 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU previous message
C01032 00097 ∂28-Aug-88 1642 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU qualification of previous message
C01034 00098 ∂29-Aug-88 1025 TAJNAI@Score.Stanford.EDU Computer Aided Instruction
C01035 00099 ∂29-Aug-88 1640 SARAIYA@SUMEX-AIM.Stanford.EDU
C01044 00100 ∂30-Aug-88 1212 ingrid@russell.stanford.edu visiting scholar cards
C01046 00101 ∂30-Aug-88 1630 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu libraries
C01048 00102 ∂31-Aug-88 1108 HEMENWAY@Score.Stanford.EDU Help Needed!
C01050 00103 ∂01-Sep-88 0957 HAILPERIN@SUMEX-AIM.Stanford.EDU PPeALS proceedings
C01051 00104 ∂01-Sep-88 1349 TAJNAI@Score.Stanford.EDU FORUM: The Beginning of a New Fiscal Year
C01054 00105 ∂01-Sep-88 1954 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu 2 Dim bin packing
C01057 00106 ∂04-Sep-88 1342 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
C01077 00107 ∂04-Sep-88 1352 X3J13-mailer Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED (version 2)
C01082 00108 ∂05-Sep-88 1439 TAJNAI@Score.Stanford.EDU faculty and student honors
C01083 00109 ∂06-Sep-88 1129 barwise@russell.stanford.edu reading list
C01086 00110 ∂06-Sep-88 1324 nilsson@Tenaya.stanford.edu reading list
C01088 00111 ∂06-Sep-88 1347 helen@russell.stanford.edu SSP
C01092 00112 ∂06-Sep-88 1441 LOGMTC-mailer Trakhtenbrot
C01095 00113 ∂06-Sep-88 2007 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu MAMLS conference at Rutgers on September 17
C01100 00114 ∂07-Sep-88 0914 AAAI-OFFICE@SUMEX-AIM.Stanford.EDU News re: CCM
C01102 00115 ∂07-Sep-88 1540 JMC@SAIL.Stanford.EDU Reading list
C01104 00116 ∂07-Sep-88 1604 ARCEO@Warbucks.AI.SRI.COM seminar, d. smith, 9/14
C01107 00117 ∂08-Sep-88 1318 LOGMTC-mailer seminar, d. smith, 9/14
C01111 00118 ∂08-Sep-88 1751 X3J13-mailer Fairfax X3 registration form
C01117 00119 ∂09-Sep-88 0904 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Papers -- Mathematical Foundations of Programming
C01125 00120 ∂09-Sep-88 1549 helen@russell.stanford.edu descriptions
C01127 00121 ∂12-Sep-88 0841 X3J13-mailer Availability of the standard
C01129 00122 ∂12-Sep-88 0938 DELAGI@SUMEX-AIM.Stanford.EDU [Dennis Gannon <gannon@iuvax.cs.indiana.edu>:]
C01135 00123 ∂12-Sep-88 1344 X3J13-mailer Common Lisp Mailing Lists
C01136 00124 ∂12-Sep-88 1954 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
C01144 00125 ∂13-Sep-88 0841 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
C01150 00126 ∂13-Sep-88 0946 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Faculty Meeting
C01152 00127 ∂13-Sep-88 0950 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Faculty Lunches
C01154 00128 ∂13-Sep-88 1001 @Score.Stanford.EDU:chandler@polya.Stanford.EDU ["Joyce R. Chandler" <chandler@polya.stanford.edu> : Faculty Lunches
C01157 00129 ∂13-Sep-88 1006 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Faculty Lunches
C01159 00130 ∂13-Sep-88 1139 X3J13-mailer Re: Issue: FUNCTION-TYPE (version 12)
C01162 00131 ∂13-Sep-88 1500 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Faculty Lunches
C01164 00132 ∂13-Sep-88 1627 LOGMTC-mailer reminder: smith seminar tomorrow (wednesday)
C01166 00133 ∂13-Sep-88 1627 LOGMTC-mailer reminder: smith seminar tomorrow (wednesday)
C01168 00134 ∂14-Sep-88 0724 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Question on Combinator Reduction
C01171 00135 ∂14-Sep-88 0734 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Papers -- RTA-89
C01180 00136 ∂14-Sep-88 0959 @Score.Stanford.EDU:chandler@polya.Stanford.EDU NSF
C01182 00137 ∂15-Sep-88 0225 X3J13-mailer "passed" cleanup issues
C01186 00138 ∂15-Sep-88 1559 DELAGI@SUMEX-AIM.Stanford.EDU ["Marc Abrams" <marc@pescadero.stanford.edu>: New mailing list on parallel simulation technical discussion]
C01190 00139 ∂15-Sep-88 1617 X3J13-mailer additional passed clean-up issues
C01192 00140 ∂15-Sep-88 1646 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Abstracts -- International Conference on Algebraic
C01198 00141 ∂16-Sep-88 0721 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Candidates
C01202 00142 ∂16-Sep-88 0726 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu CALL FOR PAPERS - WADS '89
C01207 00143 ∂16-Sep-88 0943 DELAGI@SUMEX-AIM.Stanford.EDU [gul agha <agha-gul@YALE.ARPA>: Conference Particulars]
C01215 00144 ∂16-Sep-88 1145 X3J13-mailer agenda items please
C01218 00145 ∂16-Sep-88 1157 X3J13-mailer subcommittee meetings
C01220 00146 ∂16-Sep-88 1158 @Score.Stanford.EDU:tajnai@polya.Stanford.EDU Important dates for 1989
C01222 00147 ∂17-Sep-88 1418 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Congrats!
C01225 00148 ∂19-Sep-88 1807 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Wulf Visit
C01227 00149 ∂19-Sep-88 1857 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
C01230 00150 ∂20-Sep-88 0241 @SUMEX-AIM.Stanford.EDU,@RELAY.CS.NET:OKUNO@ntt-20.ntt.jp [Revolving Seminar 9/22: Tom Knight]
C01236 00151 ∂20-Sep-88 0833 HEMENWAY@Score.Stanford.EDU Meeting Announcement
C01238 00152 ∂20-Sep-88 1124 @Score.Stanford.EDU:chandler@polya.Stanford.EDU F.Y.I.
C01240 00153 ∂20-Sep-88 1616 DELAGI@SUMEX-AIM.Stanford.EDU [sprite@spur.Berkeley.EDU (Sprite OS on SPUR): Hello World]
C01245 00154 ∂21-Sep-88 1332 TAJNAI@Score.Stanford.EDU Sunrise Club, October 4th, 7:30 a.m.
C01247 00155 ∂22-Sep-88 0754 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu STOC 88 Proceedings
C01249 00156 ∂22-Sep-88 0759 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Need Turing pictures
C01253 00157 ∂22-Sep-88 0813 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu FOCS follies
C01260 00158 ∂22-Sep-88 1118 emma@csli.Stanford.EDU CSLI Calendar, September 22, 4:1
C01268 00159 ∂22-Sep-88 1139 helen@russell.Stanford.EDU ssp descriptions
C01287 00160 ∂22-Sep-88 1529 TAJNAI@Score.Stanford.EDU Next debut
C01289 00161 ∂22-Sep-88 1617 ullman@polya.Stanford.EDU postdoc opportunity
C01293 00162 ∂22-Sep-88 1752 bresnan@russell.Stanford.EDU Re: ssp descriptions
C01295 00163 ∂23-Sep-88 0740 @Score.Stanford.EDU:tom@polya.Stanford.EDU IBM RT's/6152's demo systems
C01298 00164 ∂23-Sep-88 0836 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Survey of Bin Packing Algorithms
C01301 00165 ∂23-Sep-88 0839 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu SIGACT News
C01304 00166 ∂23-Sep-88 0902 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu
C01308 00167 ∂23-Sep-88 1053 X3J13-mailer compiler cleanup issue status
C01313 00168 ∂23-Sep-88 1054 X3J13-mailer issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
C01327 00169 ∂23-Sep-88 1054 X3J13-mailer issue EVAL-WHEN-NON-TOP-LEVEL
C01341 00170 ∂23-Sep-88 1055 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL
C01352 00171 ∂23-Sep-88 1055 X3J13-mailer issue COMPILE-ARGUMENT-PROBLEMS
C01358 00172 ∂23-Sep-88 1056 X3J13-mailer issue COMPILE-FILE-PACKAGE
C01361 00173 ∂23-Sep-88 1056 X3J13-mailer issue OPTIMIZE-DEBUG-INFO
C01366 00174 ∂23-Sep-88 1057 X3J13-mailer issue PROCLAIM-INLINE-WHERE
C01371 00175 ∂23-Sep-88 1058 X3J13-mailer **DRAFT** issue COMPILE-ENVIRONMENT-CONSISTENCY
C01385 00176 ∂23-Sep-88 1058 X3J13-mailer **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE
C01395 00177 ∂23-Sep-88 1212 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL
C01398 00178 ∂23-Sep-88 1309 @Score.Stanford.EDU:WASHINGTON@SUMEX-AIM.Stanford.EDU CSD orientation brunch
C01401 00179 ∂26-Sep-88 0927 TOM@Score.Stanford.EDU SAIL is Down
C01402 00180 ∂26-Sep-88 0930 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu New Role for Donald Knuth
C01406 00181 ∂26-Sep-88 0931 X3J13-mailer issue EVAL-WHEN-NON-TOP-LEVEL
C01413 00182 ∂26-Sep-88 0931 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4)
C01419 00183 ∂26-Sep-88 0931 X3J13-mailer issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
C01434 00184 ∂26-Sep-88 0931 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu faculty lunch
C01436 00185 ∂26-Sep-88 1041 X3J13-mailer Re: issue EVAL-WHEN-NON-TOP-LEVEL
C01439 00186 ∂26-Sep-88 1136 @Score.Stanford.EDU:chandler@polya.Stanford.EDU 9/27/88 Faculty Meeting
C01444 00187 ∂26-Sep-88 1203 X3J13-mailer Hawaii hotel arrangements
C01446 00188 ∂26-Sep-88 1632 @Score.Stanford.EDU:mayr@polya.Stanford.EDU change of address
C01448 00189 ∂26-Sep-88 1838 misha@polya.Stanford.EDU This week's AFLB talk
C01453 00190 ∂27-Sep-88 0900 @Score.Stanford.EDU:tom@polya.Stanford.EDU Chilled water shut-down
C01456 00191 ∂27-Sep-88 0940 hayes.pa@Xerox.COM Re: reading list
C01459 00192 ∂27-Sep-88 1009 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Chilled water shut-down
C01461 00193 ∂27-Sep-88 1014 TAJNAI@Score.Stanford.EDU Re: Chilled water shut-down
C01462 00194 ∂27-Sep-88 1201 @Score.Stanford.EDU:tom@polya.Stanford.EDU Chilled water shut-down
C01464 00195 ∂27-Sep-88 1418 TAJNAI@Score.Stanford.EDU IBM PC needed for blind MSCS student
C01465 00196 ∂27-Sep-88 1423 @Score.Stanford.EDU:ball@polya.Stanford.EDU Chilled water shut-down
C01467 00197 ∂27-Sep-88 1438 GILBERTSON@Score.Stanford.EDU CSD Offices Close Thurs at 4
C01469 00198 ∂27-Sep-88 1617 @Score.Stanford.EDU:rw@polya.Stanford.EDU CS Departmental Reception
C01472 00199 ∂27-Sep-88 1719 @Score.Stanford.EDU:tah@linz Getting in touch with the new students
C01474 00200 ∂28-Sep-88 0835 @Score.Stanford.EDU:tom@polya.Stanford.EDU Chilled Water Update
C01476 00201 ∂28-Sep-88 1118 helen@russell.Stanford.EDU SSP Lunch
C01478 00202 ∂28-Sep-88 1139 @Score.Stanford.EDU:RINDFLEISCH@SUMEX-AIM.Stanford.EDU Re: Facilities Committee Meeting
C01481 00203 ∂28-Sep-88 1326 LOGMTC-mailer MTC Seminar
C01486 00204 ∂28-Sep-88 1456 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu request for paper
C01490 00205 ∂28-Sep-88 1601 TAJNAI@Score.Stanford.EDU USWest Advanced Technologies sponsored research
C01493 00206 ∂28-Sep-88 1724 DELAGI@SUMEX-AIM.Stanford.EDU [Bob Sandstrom <sandstro@JUNE.CS.WASHINGTON.EDU>:]
C01498 00207 ∂28-Sep-88 1725 DELAGI@SUMEX-AIM.Stanford.EDU
C01504 00208 ∂28-Sep-88 1748 emma@csli.Stanford.EDU CSLI Calendar, September 29, 4:2
C01513 00209 ∂28-Sep-88 2240 LOGMTC-mailer Logic seminar
C01515 00210 ∂29-Sep-88 0657 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu
C01521 00211 ∂29-Sep-88 0708 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu 1989 STOC call for papers
C01528 00212 ∂29-Sep-88 1544 X3J13-mailer Fairfax attendees
C01533 00213 ∂29-Sep-88 1546 X3J13-mailer Fairfax Subcommittee Meetings Update
C01535 00214 ∂29-Sep-88 1544 X3J13-mailer Fairfax Updated Agenda DRAFT
C01538 00215 ∂29-Sep-88 1825 X3J13-mailer Re: Fairfax Updated Agenda DRAFT
C01540 00216 ∂29-Sep-88 2154 hoffman@csli.Stanford.EDU about the Symbolic Systems Forum
C01543 00217 ∂29-Sep-88 2158 hoffman@csli.Stanford.EDU Institutionalizing the Forum
C01546 00218 ∂29-Sep-88 2159 hoffman@csli.Stanford.EDU Advance Forum Timetable
C01549 00219 ∂30-Sep-88 0945 TAJNAI@Score.Stanford.EDU Student speakers for 1989 Forum meeting
C01551 00220 ∂30-Sep-88 0956 X3J13-mailer Fairfax attendees
C01553 00221 ∂30-Sep-88 1236 X3J13-mailer March '89 X3J13/ISO meeting host needed
C01555 00222 ∂30-Sep-88 1340 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu International Conference on Principal of Knowledge Representation
C01569 00223 ∂30-Sep-88 1405 X3J13-mailer Arpanet access during Fairfax meeting
C01571 00224 ∂30-Sep-88 1416 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu PROFESSORSHIPS AVAILABLE IN ITALY
C01575 00225 ∂01-Oct-88 1432 hoffman@csli.Stanford.EDU time and place of the SSP Forum
C01577 00226 ∂01-Oct-88 1524 hoffman@csli.Stanford.EDU clarification
C01579 00227 ∂01-Oct-88 2348 hoffman@csli.Stanford.EDU Oct. 7
C01581 00228 ∂03-Oct-88 0907 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Tuesday lunch
C01583 00229 ∂03-Oct-88 1122 X3J13-mailer Subcommittee Meetings at Contel
C01585 00230 ∂03-Oct-88 1252 X3J13-mailer Error terminology
C01607 00231 ∂04-Oct-88 1159 X3J13-mailer Hotel reservations for Hawaii
C01609 00232 ∂04-Oct-88 1638 helen@russell.Stanford.EDU SSP lunch meeting
C01611 00233 ∂04-Oct-88 1853 misha@polya.Stanford.EDU Next AFLB
C01614 00234 ∂04-Oct-88 2041 X3J13-mailer Re: error definitions
C01618 00235 ∂05-Oct-88 0255 bresnan@russell.Stanford.EDU Re: SSP lunch meeting
C01619 00236 ∂05-Oct-88 0920 SLOAN@Score.Stanford.EDU Water
C01620 00237 ∂05-Oct-88 0956 DELAGI@SUMEX-AIM.Stanford.EDU [Sayuri Nishimura <NISHIMURA@SUMEX-AIM.Stanford.EDU>: portable window systems implementations]
C01626 00238 ∂05-Oct-88 1003 SLOAN@Score.Stanford.EDU Water
C01627 00239 ∂05-Oct-88 1259 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu WG '89 Call for Papers
C01633 00240 ∂05-Oct-88 1405 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu the hardest language
C01636 00241 ∂05-Oct-88 1436 @Score.Stanford.EDU:DEK@SAIL.Stanford.EDU email deluge
C01638 00242 ∂05-Oct-88 1543 DELAGI@SUMEX-AIM.Stanford.EDU [Sayuri Nishimura <NISHIMURA@SUMEX-AIM.Stanford.EDU>: Re: [Sayuri Nishimura <NISHIMURA@SUMEX-AIM.Stanford.EDU>: porta
C01641 00243 ∂05-Oct-88 1545 DELAGI@SUMEX-AIM.Stanford.EDU [Sayuri Nishimura <NISHIMURA@SUMEX-AIM.Stanford.EDU>: Re: [Sayuri Nishimura <NISHIMURA@SUMEX-AIM.Stanford.EDU>: porta
C01644 00244 ∂05-Oct-88 1607 @Score.Stanford.EDU:tom@polya.Stanford.EDU Dover problems and Phase out
C01646 00245 ∂05-Oct-88 1615 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Dover problems and Phase out
C01648 00246 ∂05-Oct-88 1726 emma@csli.Stanford.EDU CSLI Calendar, October 6, 4:3
C01652 00247 ∂06-Oct-88 0733 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu CICSR Distinguished Lecture Series
C01656 00248 ∂06-Oct-88 0808 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu
C01661 00249 ∂06-Oct-88 1031 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Best Student Paper Award for 1989 STOC
C01664 00250 ∂06-Oct-88 1249 X3J13-mailer Issue: ERROR-NOT-HANDLED (Version 1)
C01670 00251 ∂06-Oct-88 1313 @Score.Stanford.EDU:jjones@polya.Stanford.EDU Re: Water
C01671 00252 ∂06-Oct-88 1317 X3J13-mailer Fairfax Registration
C01677 00253 ∂06-Oct-88 1328 X3J13-mailer Revised DRAFT Agenda
C01680 00254 ∂06-Oct-88 1517 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Minutes - 9-27 Faculty Meeting
C01682 00255 ∂06-Oct-88 1714 X3J13-mailer X3J13 issues to be emailed: stay tuned for barrage
C01684 00256 ∂06-Oct-88 1718 X3J13-mailer Issue: ALIST-NIL (Version 4)
C01692 00257 ∂06-Oct-88 1752 X3J13-mailer Arpanet access during Dallas PI meeting
C01694 00258 ∂06-Oct-88 1806 X3J13-mailer Issue: ARGUMENTS-UNDERSPECIFIED (Version 4)
C01700 00259 ∂06-Oct-88 1921 X3J13-mailer Issue: CONTAGION-ON-NUMERICAL-COMPARISONS (version 1)
C01707 00260 ∂06-Oct-88 2007 X3J13-mailer Issue: DECLARE-TYPE-FREE (Version 6)
C01717 00261 ∂06-Oct-88 2058 X3J13-mailer Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 2)
C01723 00262 ∂06-Oct-88 2058 X3J13-mailer Issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE, version 2
C01729 00263 ∂06-Oct-88 2058 X3J13-mailer Issue: EXPT-RATIO (Version 2)
C01735 00264 ∂06-Oct-88 2111 X3J13-mailer Issue FIXNUM-NON-PORTABLE (Version 3)
C01743 00265 ∂06-Oct-88 2123 X3J13-mailer Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
C01749 00266 ∂06-Oct-88 2150 X3J13-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 4)
C01759 00267 ∂07-Oct-88 0052 tah@linz Reminder: MTC Seminar
C01762 00268 ∂06-Oct-88 2057 X3J13-mailer Issue: DECLARE-FUNCTION-AMBIGUITY (version 3)
C01769 00269 ∂06-Oct-88 2058 X3J13-mailer Re: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
C01775 00270 ∂07-Oct-88 0743 CL-Cleanup-mailer Issue FIXNUM-NON-PORTABLE (Version 3)
C01777 00271 ∂07-Oct-88 0804 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu PODS-89 Symposium - Address for express delivery carriers
C01785 00272 ∂07-Oct-88 0856 @Score.Stanford.EDU:jwilson@jaguar.Stanford.EDU Discussion of the Nox-Sox building
C01787 00273 ∂07-Oct-88 0911 @Score.Stanford.EDU:ball@polya.Stanford.EDU CSD-CF Rates for 1988-89
C01794 00274 ∂07-Oct-88 0955 HEMENWAY@Score.Stanford.EDU Meeting Announcement
C01796 00275 ∂07-Oct-88 1042 hoffman@csli.Stanford.EDU First Day of the Forum
C01799 00276 ∂07-Oct-88 1302 @Score.Stanford.EDU:ball@polya.Stanford.EDU [ball@polya.Stanford.EDU: CSD-CF Rates for 1988-89]
C01807 00277 ∂07-Oct-88 1501 X3J13-mailer Issue: IN-PACKAGE-FUNCTIONALITY (Version 2)
C01813 00278 ∂07-Oct-88 1501 X3J13-mailer Issue HASH-TABLE-TESTS (Version 1)
C01821 00279 ∂07-Oct-88 1514 LOGMTC-mailer Talk on Non-standard proof normalization by Shigeki Goto
C01823 00280 ∂07-Oct-88 1616 @Score.Stanford.EDU:chandler@polya.Stanford.EDU NSF Publication
C01825 00281 ∂07-Oct-88 1642 X3J13-mailer Issue: LAMBDA-FORM (Version 3)
C01833 00282 ∂07-Oct-88 1643 X3J13-mailer Issue: NTH-VALUE (Version 3)
C01839 00283 ∂07-Oct-88 1643 misha@polya.Stanford.EDU Next AFLB.
C01843 00284 ∂07-Oct-88 1721 @Score.Stanford.EDU:tom@polya.Stanford.EDU MJH cooling problems
C01845 00285 ∂07-Oct-88 2151 X3J13-mailer Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
C01853 00286 ∂07-Oct-88 2151 X3J13-mailer Issue: SETF-FUNCTION-VS-MACRO (version 3)
C01873 00287 ∂07-Oct-88 2152 X3J13-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)
C01885 00288 ∂07-Oct-88 2151 X3J13-mailer Issue: RETURN-VALUES-UNSPECIFIED (Version 4)
C01890 00289 ∂07-Oct-88 2150 X3J13-mailer Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
C01898 00290 ∂07-Oct-88 2206 X3J13-mailer STEP-ENVIRONMENT, version 3
C01903 00291 ∂07-Oct-88 2215 X3J13-mailer Issue: STREAM-ACCESS (version 1)
C01912 00292 ∂07-Oct-88 2317 X3J13-mailer Issue: SUBTYPEP-TOO-VAGUE (Version 4)
C01920 00293 ∂07-Oct-88 2334 X3J13-mailer Issue: TAGBODY-CONTENTS (Version 4)
C01928 00294 ∂07-Oct-88 2343 X3J13-mailer Issue: VARIABLE-LIST-ASYMMETRY (Version 2)
C01933 00295 ∂08-Oct-88 1021 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Thinking Machines
C01935 00296 ∂08-Oct-88 1032 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu visitors
C01940 00297 ∂08-Oct-88 1041 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu colloquium
C01943 00298 ∂08-Oct-88 1150 CL-Cleanup-mailer Issue: RETURN-VALUES-UNSPECIFIED (Version 4)
C01946 00299 ∂08-Oct-88 1229 X3J13-mailer REPLY-TO: CL-CLEANUP@Sail.Stanford.Edu
C01948 00300 ∂08-Oct-88 1253 X3J13-mailer DRAFT Issue: CLOSED-STREAM-OPERATIONS (Version 2)
C01954 00301 ∂08-Oct-88 1320 X3J13-mailer DRAFT Issue: COERCE-INCOMPLETE (Version 1)+
C01968 00302 ∂08-Oct-88 1329 X3J13-mailer DRAFT Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)
C01989 00303 ∂08-Oct-88 1441 X3J13-mailer DRAFT Issue: DEFPACKAGE (version 6)
C02005 00304 ∂08-Oct-88 1547 X3J13-mailer DRAFT Issue: DEFSTRUCT-REDEFINITION (Version 1)
C02012 00305 ∂08-Oct-88 1605 X3J13-mailer Issue: DESCRIBE-INTERACTIVE (Version 2)
C02018 00306 ∂08-Oct-88 1651 X3J13-mailer Issue: EXIT-EXTENT (Version 3)
C02033 00307 ∂08-Oct-88 1651 X3J13-mailer Issue: EQUAL-STRUCTURE (Version 5)
C02042 00308 ∂08-Oct-88 1651 X3J13-mailer DRAFT Issue: DOTTED-MACRO-FORMS (Version 2)
C02049 00309 ∂08-Oct-88 1703 X3J13-mailer DRAFT Issue: FORMAT-PRETTY-PRINT (version 5)
C02059 00310 ∂08-Oct-88 1726 X3J13-mailer DRAFT Issue: FUNCTION-COERCE-TIME (Version 2)
C02072 00311 ∂08-Oct-88 1726 X3J13-mailer DRAFT Issue: FUNCTION-COMPOSITION (Version 2)
C02082 00312 ∂08-Oct-88 1741 X3J13-mailer DRAFT Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
C02093 00313 ∂08-Oct-88 1741 X3J13-mailer DRAFT Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)
C02109 00314 ∂08-Oct-88 1741 X3J13-mailer DRAFTIssue: HASH-TABLE-ACCESS (version 1)
C02115 00315 ∂08-Oct-88 1741 X3J13-mailer DRAFT Issue: FUNCTION-DEFINITION (Version 1)
C02135 00316 ∂08-Oct-88 1751 X3J13-mailer DRAFT Issue: HASH-TABLE-PRINTED-PREPRESENTATION (Version 2)
C02145 00317 ∂08-Oct-88 1902 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU disk rates
C02146 00318 ∂08-Oct-88 1956 X3J13-mailer Issue: LISP-SYMBOL-REDEFINITION (Version 3)
C02154 00319 ∂08-Oct-88 2035 X3J13-mailer Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 2)
C02161 00320 ∂08-Oct-88 2043 X3J13-mailer Issue: PACKAGE-CLUTTER (Version 4)
C02176 00321 ∂08-Oct-88 2055 X3J13-mailer Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)
C02191 00322 ∂08-Oct-88 2106 X3J13-mailer PRINT-CIRCLE-STRUCTURE (Version 3)
C02199 00323 ∂08-Oct-88 2112 X3J13-mailer DRAFT Issue: PROCLAIM-LEXICAL (Version 8)
C02221 00324 ∂08-Oct-88 2129 X3J13-mailer DRAFT Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
C02249 00325 ∂08-Oct-88 2134 X3J13-mailer Issue: REQUIRE-PATHNAME-DEFAULTS (version 2)
C02258 00326 ∂08-Oct-88 2146 X3J13-mailer Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
C02263 00327 ∂08-Oct-88 2153 X3J13-mailer Issue: SETF-SUB-METHODS (Version 5)
C02290 00328 ∂08-Oct-88 2203 X3J13-mailer DRAFT Issue SYMBOL-MACROLET-SEMANTICS, Version 4
C02299 00329 ∂08-Oct-88 2159 X3J13-mailer DRAFT Issue: STREAM-INFO (Version 5)
C02325 00330 ∂08-Oct-88 2159 X3J13-mailer DRAFT Issue: SYMBOL-MACROLET-DECLARE (version 1)
C02329 00331 ∂08-Oct-88 2211 X3J13-mailer DRAFT Issue: TEST-NOT-IF-NOT (Version 2)
C02338 00332 ∂08-Oct-88 2216 X3J13-mailer DRAFT Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
C02347 00333 ∂08-Oct-88 2211 X3J13-mailer DRAFT Issue: TAILP-NIL (Version 2)
C02355 00334 ∂09-Oct-88 0230 X3J13-mailer Draft Issue: CLOS-CONDITIONS (Version 3)
C02370 00335 ∂09-Oct-88 1359 @Score.Stanford.EDU:Mailer@SAIL.Stanford.EDU disk use charges
C02377 00336 ∂10-Oct-88 0813 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Facutly Lunch, Tuesday 10/11/88
C02379 00337 ∂10-Oct-88 1425 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Concurrency '88 -- Final Program
C02390 00338 ∂11-Oct-88 1434 @Score.Stanford.EDU:hayes.pa@Xerox.COM Re: disk use charges
C02392 00339 ∂11-Oct-88 2008 DELAGI@SUMEX-AIM.Stanford.EDU [Eugene Miya <eugene@orville.nas.nasa.gov>:]
C02406 00340 ∂12-Oct-88 1233 @Score.Stanford.EDU:katiyar@polya.Stanford.EDU potluck volunteers!
C02409 00341 ∂12-Oct-88 1539 @Score.Stanford.EDU:WIEDERHOLD@SUMEX-AIM.Stanford.EDU Re: disk use charges
C02411 00342 ∂12-Oct-88 1822 emma@csli.Stanford.EDU CSLI Calendar, October 13, 4:4
C02425 00343 ∂12-Oct-88 1833 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu important meeting
C02428 00344 ∂12-Oct-88 2009 LOGMTC-mailer Mark Manasse's email address?
C02429 00345 ∂12-Oct-88 2351 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu Re: disk use charges
C02433 00346 ∂13-Oct-88 1004 emma@csli.Stanford.EDU CSLI Calendar, addition
C02436 00347 ∂13-Oct-88 1403 hoffman@csli.Stanford.EDU Symbolic Systems Forum Oct. 14
C02438 00348 ∂13-Oct-88 1528 tah@linz MTC Seminar
C02441 00349 ∂13-Oct-88 1532 @Score.Stanford.EDU:WIEDERHOLD@SUMEX-AIM.Stanford.EDU Re: disk use charges
C02445 00350 ∂13-Oct-88 1903 @Score.Stanford.EDU:hayes.pa@Xerox.COM Re: disk use charges
C02449 00351 ∂13-Oct-88 1910 @Score.Stanford.EDU:vavasis@polya.Stanford.EDU charge rates
C02452 00352 ∂14-Oct-88 1105 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Columbia theory seminars near FOCS
C02458 00353 ∂14-Oct-88 1257 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu LICS-89 DEADLINE
C02462 00354 ∂14-Oct-88 1418 @Score.Stanford.EDU:wheaton@athena.stanford.edu Special-Needs Budget
C02465 00355 ∂14-Oct-88 1427 X3J13-mailer Issue: RANGE-OF-COUNT-KEYWORD (Version 3)
C02476 00356 ∂16-Oct-88 2322 misha@polya.Stanford.EDU Next AFLB is on Tuesday!
C02481 00357 ∂17-Oct-88 0814 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Tenured Faculty Meeting
C02483 00358 ∂17-Oct-88 0910 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu ICLP89 --- CFP
C02492 00359 ∂17-Oct-88 1205 helen@russell.Stanford.EDU SSP-lunch
C02494 00360 ∂17-Oct-88 1233 DAVIS@Score.Stanford.EDU scheduling book
C02495 00361 ∂17-Oct-88 1249 @Score.Stanford.EDU:chandler@polya.Stanford.EDU 10/19 Faculty Lunch
C02497 00362 ∂17-Oct-88 1318 @SUMEX-AIM.Stanford.EDU:mxh@ksl.Stanford.EDU Hoare on SIMD
C02499 00363 ∂17-Oct-88 1436 ullman@polya.Stanford.EDU ICLP call
C02507 00364 ∂18-Oct-88 0830 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu WOBCATS
C02511 00365 ∂18-Oct-88 0835 DELAGI@SUMEX-AIM.Stanford.EDU [Bart Miller <bart@SPEEDY.CS.WISC.EDU>:]
C02516 00366 ∂18-Oct-88 0839 THAPAR@SUMEX-AIM.Stanford.EDU debugging workshop
C02517 00367 ∂18-Oct-88 0850 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu AMAST -- Call for Abstracts
C02525 00368 ∂18-Oct-88 0912 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu Re: Tenured Faculty Meeting
C02528 00369 ∂18-Oct-88 1036 @polya.Stanford.EDU:chomicki@brillig.umd.edu Rita G. Minker
C02538 00370 ∂18-Oct-88 1722 hoffman@csli.Stanford.EDU Symbolic Systems Forum Oct. 21 (Friday)
C02541 00371 ∂18-Oct-88 2146 CL-Cleanup-mailer DRAFT Issue: TEST-NOT-IF-NOT (Version 2)
C02543 00372 ∂19-Oct-88 1219 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Wilkinson Fellowship at Argonne Nat Lab
C02549 00373 ∂19-Oct-88 1350 barwise@russell.Stanford.EDU A graduate program in Philosophy and SS
C02555 00374 ∂19-Oct-88 1352 barwise@russell.Stanford.EDU A graduate program in Philosophy and SS
C02561 00375 ∂19-Oct-88 1407 ULLMAN@Score.Stanford.EDU house available
C02562 00376 ∂19-Oct-88 1823 emma@csli.Stanford.EDU CSLI Calendar, October 20, 4:5
C02574 00377 ∂20-Oct-88 0958 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Thinking Machines
C02576 00378 ∂20-Oct-88 1244 hoffman@csli.Stanford.EDU Symbolic Systems Forum Oct. 28
C02579 00379 ∂20-Oct-88 1317 Kay.pa@Xerox.COM Re: SSP-lunch
C02581 00380 ∂20-Oct-88 1512 hoffman@csli.Stanford.EDU some Symbolic System Forums Announcements
C02584 00381 ∂20-Oct-88 2352 tah@linz MTC Seminar
C02588 00382 ∂21-Oct-88 0002 tah@linz MTC Seminar
C02592 00383 ∂21-Oct-88 0843 emma@russell.Stanford.EDU SSP faculty lunch
C02593 00384 ∂21-Oct-88 0844 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu SIGAL Workshop on Algorithms in Japan -- Call for Papers
C02597 00385 ∂21-Oct-88 0844 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Structure in Complexity Theory -- Call for Papers
C02604 00386 ∂21-Oct-88 1413 hoffman@csli.Stanford.EDU one correction
C02606 00387 ∂21-Oct-88 1513 @Score.Stanford.EDU:chandler@polya.Stanford.EDU The Connection Machine
C02608 00388 ∂21-Oct-88 1631 @SUMEX-AIM.Stanford.EDU:mxh@ksl.stanford.edu Frontiers '88 notes
C02613 00389 ∂22-Oct-88 1826 @polya.Stanford.EDU:gangolli@wolvesden.Stanford.EDU This week's talk
C02615 00390 ∂22-Oct-88 1826 @polya.Stanford.EDU:gangolli@wolvesden.Stanford.EDU AFLB talk
C02618 00391 ∂22-Oct-88 1909 LOGMTC-mailer anyone interested?
C02620 00392 ∂24-Oct-88 0813 @SUMEX-AIM.Stanford.EDU:mxh@ksl.stanford.edu [weening@gang-of-four.stanford.edu (Joe Weening) : PhD Oral seminar
C02626 00393 ∂24-Oct-88 0946 DAVIS@Score.Stanford.EDU room schedulig
C02627 00394 ∂24-Oct-88 1003 @Score.Stanford.EDU:winograd@loire.stanford.edu Meeting of Undergraduate Major committee - MON 10/31, 3pm - MJH220
C02634 00395 ∂24-Oct-88 1133 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Meeting of Undergraduate Major committee - MON 10/31, 3pm - MJH220
C02637 00396 ∂24-Oct-88 1519 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Meeting of Undergraduate Major committee - MON 10/31, 3pm - MJH220
C02640 00397 ∂24-Oct-88 1556 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: Meeting of Undergraduate Major committee - MON 10/31, 3pm - MJH220
C02642 00398 ∂24-Oct-88 1641 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Faculty Lunch - 10/25
C02644 00399 ∂24-Oct-88 1747 @SUMEX-AIM.Stanford.EDU:Acuff@KSL.Stanford.EDU New file server
C02647 00400 ∂24-Oct-88 2351 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu Re: Meeting of Undergraduate Major committee - MON 10/31, 3pm - MJH220
C02650 00401 ∂25-Oct-88 0809 @Score.Stanford.EDU:jlh@vsop.Stanford.EDU Re: Meeting of Undergraduate Major committee - MON 10/31, 3pm - MJH220
C02653 00402 ∂25-Oct-88 0852 X3J13-mailer Proposed US Position Statement
C02659 00403 ∂25-Oct-88 0858 DELAGI@SUMEX-AIM.Stanford.EDU [wall@decwrl.dec.com (David Wall): BASS 15]
C02672 00404 ∂25-Oct-88 0944 @Score.Stanford.EDU:jwilson@jaguar.Stanford.EDU Meeting of CSD Database committee
C02674 00405 ∂25-Oct-88 0950 @Score.Stanford.EDU:jwilson@jaguar.Stanford.EDU Where the meeting of CSD Database committee will be held
C02676 00406 ∂25-Oct-88 1013 @Score.Stanford.EDU:dill@amadeus.STANFORD.EDU undergrad major
C02679 00407 ∂25-Oct-88 1030 STAGER@Score.Stanford.EDU Preliminary Class Lists
C02681 00408 ∂25-Oct-88 1038 barwise@russell.Stanford.EDU ra support for new program
C02683 00409 ∂25-Oct-88 1217 @Score.Stanford.EDU:WIEDERHOLD@SUMEX-AIM.Stanford.EDU Re: Preliminary Class Lists
C02685 00410 ∂25-Oct-88 1403 DELAGI@SUMEX-AIM.Stanford.EDU [kaplan%kaplan.cs.uiuc.edu@a.cs.uiuc.edu (Simon Kaplan): Concurrent Object-Based Programming List]
C02693 00411 ∂25-Oct-88 1405 X3J13-mailer Comments on Cleanup issues due within two weeks
C02696 00412 ∂26-Oct-88 0619 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu code wanted for exact tsp and reduce
C02699 00413 ∂26-Oct-88 0624 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu funny-bug
C02702 00414 ∂26-Oct-88 1036 @Score.Stanford.EDU:jwilson@jaguar.Stanford.EDU Availability of Mac Plus and IBM XT machines
C02705 00415 ∂26-Oct-88 1424 @Score.Stanford.EDU:katiyar@polya.Stanford.EDU CSD Autumn Potluck!
C02711 00416 ∂26-Oct-88 1649 @Score.Stanford.EDU:jwilson@jaguar.Stanford.EDU CSD Autumn Potluck program may use vi or emacs
C02713 00417 ∂26-Oct-88 1840 emma@csli.Stanford.EDU CSLI Calendar, October 27, 4:6
C02727 00418 ∂26-Oct-88 1925 X3J13-mailer Proposed US Position Statement
C02729 00419 ∂27-Oct-88 1040 TAJNAI@Score.Stanford.EDU interested in spending sabbatical at IBM Tokyo Research Labs?
C02731 00420 ∂27-Oct-88 1441 DEWERK@Score.Stanford.EDU CS-TAC
C02733 00421 ∂27-Oct-88 1521 @Score.Stanford.EDU:dash@polya.Stanford.EDU Re: CS-TAC
C02735 00422 ∂27-Oct-88 1603 @Score.Stanford.EDU:warren@Portia.stanford.edu Re: CS-TAC
C02739 00423 ∂27-Oct-88 1623 DELAGI@SUMEX-AIM.Stanford.EDU [kaplan%kaplan.cs.uiuc.edu@a.cs.uiuc.edu (Simon Kaplan): Concurrent Object-Based Programming List]
C02747 00424 ∂27-Oct-88 1645 hoffman@csli.Stanford.EDU SSP Forum Oct. 28
C02749 00425 ∂27-Oct-88 1737 @Score.Stanford.EDU:dwhitney@Portia.stanford.edu Re: CS-TAC
C02751 00426 ∂27-Oct-88 1801 @Score.Stanford.EDU:koch@polya.Stanford.EDU Re: CS-TAC
C02753 00427 ∂27-Oct-88 2254 @Score.Stanford.EDU:seidel@Portia.stanford.edu Re: CS-TAC
C02755 00428 ∂27-Oct-88 2329 @polya.Stanford.EDU:tah@linz MTC Seminar Today
C02757 00429 ∂27-Oct-88 2339 @polya.Stanford.EDU:tah@linz MTC Seminar, 2nd Down
C02759 00430 ∂28-Oct-88 0000 @Score.Stanford.EDU:gandalf@csli.Stanford.EDU Please!
C02760 00431 ∂28-Oct-88 0347 X3J13-mailer mailing list update
C02761 00432 ∂28-Oct-88 1136 @Score.Stanford.EDU:tom@polya.Stanford.EDU [GX.LOO@Forsythe.Stanford.EDU: Mathematica Presentation 11/2/88]
C02765 00433 ∂28-Oct-88 1607 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu THE MATHEMATICAL REVOLUTION INSPIRED BY COMPUTING
C02773 00434 ∂28-Oct-88 1629 REGES@Score.Stanford.EDU addendum to Tom's msg RE Wolfram/Mathematica
C02776 00435 ∂31-Oct-88 0830 @Score.Stanford.EDU:chandler@polya.Stanford.EDU This weeks faculty lunch....
C02778 00436 ∂31-Oct-88 1519 GENESERETH@Score.Stanford.EDU PhD Program proposal
C02785 00437 ∂31-Oct-88 1652 misha@polya.Stanford.EDU Next AFLB - UNUSUAL TIME AND PLACE!
C02788 00438 ∂01-Nov-88 0011 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: PhD Program proposal
C02794 00439 ∂01-Nov-88 0016 @Score.Stanford.EDU:jlh@vsop.Stanford.EDU Re: PhD Program proposal
C02796 00440 ∂01-Nov-88 1139 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu a desperate call for candidates
C02799 00441 ∂01-Nov-88 1237 X3J13-mailer March meeting
C02801 00442 ∂01-Nov-88 1245 X3J13-mailer March meeting
C02803 00443 ∂01-Nov-88 1927 @Score.Stanford.EDU:gio@ksl.stanford.edu Re: PhD Program proposal
C02805 00444 ∂02-Nov-88 0930 X3J13-mailer Hawaii hotel reservations reminder
C02807 00445 ∂02-Nov-88 1108 @Score.Stanford.EDU:root@polya.Stanford.EDU polya account
C02808 00446 ∂02-Nov-88 1553 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu NSF support for algorithms and parallel computing systems
C02815 00447 ∂02-Nov-88 1604 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu PODC Call for Papers:
C02823 00448 ∂02-Nov-88 1612 X3J13-mailer Re: Proposed US Position Statement
C02831 00449 ∂02-Nov-88 1836 emma@csli.Stanford.EDU CSLI Calendar, November 3, 4:7
C02838 00450 ∂02-Nov-88 1849 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu NSF support for algorithms and parallel computing systems
C02845 00451 ∂02-Nov-88 1902 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu PODC Call for Papers:
C02853 00452 ∂03-Nov-88 0923 TAJNAI@Score.Stanford.EDU Call for Papers for Computer Forum
C02856 00453 ∂03-Nov-88 1033 @Score.Stanford.EDU:eaf@ksl.stanford.edu Re: Call for Papers for Computer Forum
C02859 00454 ∂03-Nov-88 1419 @polya.Stanford.EDU:tah@linz.stanford.edu MTC Seminar
C02861 00455 ∂03-Nov-88 1531 snoeyink@polya.Stanford.EDU Thesis proposal presentation 4pm Monday, Nov 7
C02864 00456 ∂04-Nov-88 1135 BSCOTT@Score.Stanford.EDU AFOSR Booklet
C02865 00457 ∂04-Nov-88 1255 hoffman@csli.Stanford.EDU Symbolic Systems Forum
C02867 00458 ∂04-Nov-88 1349 PATRICIA@Score.Stanford.EDU Luncheon
C02869 00459 ∂04-Nov-88 1517 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU FAX Machine
C02871 00460 ∂07-Nov-88 0639 X3J13-mailer Re: Proposed US Position Statement
C02873 00461 ∂07-Nov-88 0930 ruben@apple.com Re: Symbolic Systems Forum Oct. 21 (Friday)
C02875 00462 ∂07-Nov-88 1129 TAJNAI@Score.Stanford.EDU Call for nominations for Bell Fellowship
C02877 00463 ∂07-Nov-88 1429 vavasis@polya.Stanford.EDU bats is THIS FRIDAY!!
C02889 00464 ∂07-Nov-88 1453 STAGER@Score.Stanford.EDU Final exams
C02892 00465 ∂07-Nov-88 1507 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Facutly Lunch
C02894 00466 ∂07-Nov-88 1517 X3J13-mailer US Position Statement (Version 2)
C02903 00467 ∂07-Nov-88 2009 hoffman@csli.Stanford.EDU reminder
C02904 00468 ∂07-Nov-88 2010 hoffman@csli.Stanford.EDU Symbolic Systems Forum Nov. 11
C02907 00469 ∂08-Nov-88 1247 snoeyink@polya.Stanford.EDU bats rides
C02910 00470 ∂08-Nov-88 1252 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu FCT 89
C02915 00471 ∂08-Nov-88 1719 gurevich@polya.Stanford.EDU bats rides
C02917 00472 ∂08-Nov-88 1722 peters@russell.Stanford.EDU Stanford academic recruiting
C02919 00473 ∂08-Nov-88 1829 TAJNAI@Score.Stanford.EDU encourage students to send resumes to Forum
C02922 00474 ∂08-Nov-88 1908 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Faculty Lunch - 11/8/88
C02924 00475 ∂09-Nov-88 1137 X3J13-mailer Official US Position
C02932 00476 ∂09-Nov-88 1205 aaai@sumex-aim.stanford.edu test
C02933 00477 ∂09-Nov-88 1310 TAJNAI@Score.Stanford.EDU Please forward to CS professors.
C02935 00478 ∂09-Nov-88 1325 @Score.Stanford.EDU:rokicki@polya.Stanford.EDU Programming Contest
C02937 00479 ∂09-Nov-88 1601 @Score.Stanford.EDU:winograd@loire.stanford.edu Re: PhD Program proposal
C02941 00480 ∂09-Nov-88 1814 misha@polya.Stanford.EDU Next aflb
C02942 00481 ∂09-Nov-88 1847 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: PhD Program proposal
C02944 00482 ∂10-Nov-88 0115 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu PhD Program?
C02947 00483 ∂10-Nov-88 0935 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Next Week's Faculty Lunch
C02949 00484 ∂10-Nov-88 0936 emma@csli CSLI Calendar, November 10, 4:8
C02957 00485 ∂10-Nov-88 1342 SLOAN@Score.Stanford.EDU Holidays
C02959 00486 ∂11-Nov-88 1022 aaai@sumex-aim.stanford.edu January Conference Call
C02961 00487 ∂11-Nov-88 1205 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu popl program
C02970 00488 ∂11-Nov-88 1405 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Marist College -- Colloquium Series 88/89
C02975 00489 ∂11-Nov-88 1644 GENESERETH@Score.Stanford.EDU New building
C02980 00490 ∂11-Nov-88 1746 @Score.Stanford.EDU:jwilson@jaguar.Stanford.EDU New building
C02982 00491 ∂11-Nov-88 1827 @Score.Stanford.EDU:bhayes@polya.Stanford.EDU bboard posting
C02984 00492 ∂12-Nov-88 1420 @Score.Stanford.EDU:winograd@loire.stanford.edu Re: PhD Program?
C02988 00493 ∂12-Nov-88 1508 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu Re: PhD Program?
C02992 00494 ∂13-Nov-88 1256 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu DEC's new MIPS-based workstation
C02994 00495 ∂14-Nov-88 0743 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Faculty Lunch - 11/15/88
C02996 00496 ∂14-Nov-88 0804 X3J13-mailer Re: Hawaii hotel reservations reminder
C02998 00497 ∂14-Nov-88 1030 @Score.Stanford.EDU:linton@interviews.stanford.edu Re: PhD Program?
C03001 00498 ∂14-Nov-88 1104 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Final exams
C03004 00499 ∂14-Nov-88 1130 X3J13-mailer Ignore that message
C03005 00500 ∂14-Nov-88 1150 @Score.Stanford.EDU:jcm@ra.stanford.edu PhD Program? (philosophical discussion)
C03008 00501 ∂14-Nov-88 1203 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: New building
C03010 00502 ∂15-Nov-88 0903 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Application of Splay Trees to Data Compression
C03013 00503 ∂15-Nov-88 1014 betsy@russell.Stanford.EDU meeting reminder
C03014 00504 ∂15-Nov-88 1033 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu New building
C03016 00505 ∂15-Nov-88 1059 @Score.Stanford.EDU:rse@sumex-aim.stanford.edu Re: New building
C03019 00506 ∂15-Nov-88 1326 GENESERETH@Score.Stanford.EDU Re: New building
C03020 00507 ∂15-Nov-88 1529 LOGMTC-mailer Smuel Safra will speak at the next AFLB
C03023 00508 ∂15-Nov-88 1529 LOGMTC-mailer Smuel Safra will speak at the next AFLB
C03026 00509 ∂16-Nov-88 1028 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Visit of...
C03028 00510 ∂16-Nov-88 1238 barwise@russell.Stanford.EDU SSP grad fellowship
C03032 00511 ∂16-Nov-88 1239 TAJNAI@Score.Stanford.EDU Resume Situation a Disaster!
C03036 00512 ∂16-Nov-88 1559 hoffman@csli.Stanford.EDU this weeks forum (nov. 18)
C03038 00513 ∂16-Nov-88 1606 barwise@russell.Stanford.EDU Traugott's email address
C03039 00514 ∂16-Nov-88 1759 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu POPL '89 Registration Information
C03048 00515 ∂16-Nov-88 1759 emma@csli.Stanford.EDU CSLI Calendar, November 17, 4:9
C03057 00516 ∂17-Nov-88 1549 TAJNAI@Score.Stanford.EDU Speakers for 1989 Forum Meeting
C03060 00517 ∂17-Nov-88 1724 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU
C03065 00518 ∂17-Nov-88 1926 SHOHAM@Score.Stanford.EDU department colloquium
C03067 00519 ∂17-Nov-88 2247 tah@linz MTC Seminar
C03071 00520 ∂18-Nov-88 0108 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU re: New building
C03073 00521 ∂18-Nov-88 0951 @Score.Stanford.EDU:winograd@loire.stanford.edu Student evaluations
C03077 00522 ∂18-Nov-88 1054 @Score.Stanford.EDU:binford@Boa-Constrictor.Stanford.EDU New building
C03079 00523 ∂18-Nov-88 1106 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: New building
C03081 00524 ∂18-Nov-88 1200 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: New building
C03091 00525 ∂18-Nov-88 1432 @Score.Stanford.EDU:%orc.olivetti.com@NET.BIO.NET Re: Speakers for 1989 Forum Meeting
C03094 00526 ∂18-Nov-88 1620 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: Student evaluations
C03103 00527 ∂19-Nov-88 0903 LOGMTC-mailer Albert Meyer's TYPES mailing list
C03105 00528 ∂19-Nov-88 1330 @Score.Stanford.EDU:gio@sumex-aim.stanford.edu Re: New building
C03107 00529 ∂19-Nov-88 1819 LOGMTC-mailer Smuel Safra will speak at the next AFLB
C03110 ENDMK
C⊗;
∂10-Jul-88 0242 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #41
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Jul 88 02:42:08 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA21723; Sun, 10 Jul 88 00:34:16 PDT
Date: Sun, 10 Jul 88 00:34:16 PDT
From: Chuck Restivo <restivo@polya.Stanford.EDU>
Message-Id: <8807100734.AA21723@polya.Stanford.EDU>
To: restivo@polya.Stanford.EDU
Subject: PROLOG DIGEST V6 #41
Date: Sun 10 July 1988 02:53-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@POLYA.STANFORD.EDU>
Reply-to: PROLOG@POLYA.STANFORD.EDU>
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #41
To: PROLOG@POLYA.STANFORD.EDU
PROLOG Digest Sunday, 10 July 1988 Volume 6 : Issue 41
Today's Topics:
λλQuery - Reference Guide,
λFamiliar Debate - Procedural v. Non-Procedural,
Implementation - GNU v. Unipress
----------------------------------------------------------------------------------------------------------------------------
Date: 20 Jun 88 17:54:42 GMT
From: bgsuvax!maner@tut.cis.ohio-state.edu (Walter Maner)
Subject: NEED PROLOG QUICK REFERENCE GUIDE
I am trying to compress essential information for first-time Prolog users
into a single sheet of paper (back and front). Any suggestions about
what should go there? Any pointers to existing quick-reference sheets?
------------------------------
Date: 20 Jun 88 22:32:45 GMT
From: debray@arizona.edu (Saumya Debray)
Subject: NEED PROLOG QUICK REFERENCE GUIDE
"Variables of the world, unify!"
-- Saumya Debray
------------------------------
Date: 30 May 88 04:03:14 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Subject: Prolog Is Semi-Procedural
In article <5500005@uiucdcsm>, mccaugh@uiucdcsm.cs.uiuc.edu writes:
> I submit that "prolog" - the so-called "logic-programming" language - is
> (among other disclaimers) NOT altogether the "declarative" non-procedural
> language it is advertised to be. Case in point:
> sum(0,0).
> sum(N,M) :- N1 = N-1, sum(N1,M1), M = M1+N.
> In a truly non-procedural (i.e. (I anticipate controversy here) non-
> deterministic) language, the test: N>0 should not be necessary, and yet
> (as we know), it must appear to avoid stack-overflow (in CPROLOG, UNSW-
> PROLOG, anyway).
The conclusion is valid, but the argument is bogus. {What's with this
N1 = N-1 business, anyway? In C Prolog the code as written will never
succeed for any first argument other than 0. E.g.
sum(1, X) -> sum(1-1, M1) -> sum(1-1-1, M1') -> sum(1-1-1-1, M1") -> ...}
Claim: there is no "declarative" language permitting recursive declarations
currently existing in which control issues can be ignored.
(Lazy ML, Miranda, even the relational algebra, support this claim.)
While in this case it is straightforward to show that for sum/2 to succeed
its first argument must be a non-negative integer, in general it is at least
as hard as solving the halting problem (insert standard trivial proof here).
"Non-procedural" and "non-deterministic" are orthogonal concepts.
E.g. ICON is non-deterministic but non-procedural, ML is non-procedural
but not non-deterministic, Pascal is neither.
------------------------------
Date: 31 May 88 11:08:40 GMT
From: mcvax!ukc!warwick!expya!exsb.cs.exeter.ac.uk!jtr@uunet.uu.net (Jason Trenouth)
Subject: GNU vrs UNIPRESS
Walter Maner writes:
> We have the happy dilemma of deciding whether to use the excellent Unipress
> EMACS which come bundled with Quintus Prolog or integrating the GNU EMACS,
> already installed, with Quintus Prolog. Any observations of experiences
> would be welcome. I suppose our preference is to interface with GNU if that
> is easily accomplished without loss of functionality.
and Martin Carroll replies:
>> GNU GNU GNU GNU GNU GNU GNU
>>
>> I hate unipress.
I've been through five stages of editor with Quintus Prolog.
Initially I used the UNIPRESS Emacs that QP came with. Gradually I discovered
that this was not the same as the GNU Emacs that the rest of the department
used. The differences were mostly little irritations, but they were all with
UNIPRESS.
For a short while I used GNU Emacs, but I became frustrated by the lack of a
handy rodent. Then I turned to the SPY editor (UK mouse-based editor).
However, its impossible to run a Prolog subprocess through it sensibly, and I
moved on to the Sun's own "textedit". This had the added advantage of having
the same interface as the "mailtool" and "cmdtool" (for those who know what
I'm talking about).
Then the department began using the Sun-interfaced GNU Emacs and my troubles
were over. Yessiree, I'm a BORN AGAIN GNU lover.
CONS:
No compile option.
Quintus Prolog doesn't get tricked into believing the buffer is the
original file (i.e. multifile warnings if you switch between buffer
consults and normal consults).
No help file interface.
Some unsupported libraries effected (e.g. big_text).
No find definition power (Ouch this hurts!), and not linked to
debugger.
Not supported.
PROS
GNU Emacs has an all-round better feel than UNIPRESS.
Better integrated with a Sun workstation (if you got one!).
If GNU Emacs is already widely used within your organisation, then so
much the better for the Prolog user who doesn't need to change his
editor to read any mail etc. (OK UNIPRESS can do other things but see
below.)
To keep two comparably full versions of Emacs around is an enourmous
waste of disk space! What could happen (i.e. happened here) is that it
was only possible to use a stunted version of UNIPRESS Emacs - thus
making GNU Emacs infinitely better in any feature comparison.
I gather that GNU is more powerful anyway (unconfirmed). Certainly,
some hardware manufacturers (e.g. Pyramid) started supplying GNU in
addition to UNIPRESS because their user-base prefers it.
The only feature that I wished for was "find-definition". GNU Emacs has a more
general/powerful "find-tag" feature. However, it relies on an associated
program called ETAGS which currently only understands C, FORTRAN, LISP, and
LATEX (text formatter). Rather than waiting for Richard Stallman's (Ohmmme)
merry men to correct this deficiency I recently wrote PTAGS. This creates a
TAG FILE from a Prolog file(s) that GNU Emacs can use to implement "find-tag"
for Prolog. PTAGS is written in Prolog (~10K) and is sort of available after I
check with our system admin about the proper place to post it.
"If the feel is against you then argue the features.
If the features are against you then argue the feel.
If they are both against you, call the other Emacs names."
--------------------------------
Wed, 8 Jun 88 05:47:20 PDT
Date: 7 Jun 88 07:21:28 GMT
Subject: Re: GNU vrs UNIPRESS
In article <500@expya.UUCP> jtr@exsb.cs.exeter.ac.uk (Jason Trenouth) writes:
>Walter Maner writes:
>Then the department began using the Sun-interfaced GNU Emacs and my troubles
>were over. Yessiree, I'm a BORN AGAIN GNU lover.
There is a Prolog-mode for GNU Emacs that we got from Aerospace.
I'll contrast it with Trenouth's points.
> No compile option.
Meta-k and Meta-i are there.
> Quintus Prolog doesn't get tricked into believing the buffer is the
> original file (i.e. multifile warnings if you switch between buffer
> consults and normal consults).
{don't know about this}
> No help file interface.
It's all there.
> Some unsupported libraries effected (e.g. big_text).
The \042(command)\041 escape method is handled, so this should work.
> No find definition power (Ouch this hurts!), and not linked to
> debugger.
Find-definition is there.
> Not supported.
Ah, there is that.
This package does a really thorough job of imitating the Emacs interface
documented in the Quintus manuals. We'd like to distribute it. The trouble
is, as it has always been, the GNU "copyleft". It looks as though it _may_
be safe for us to give out the occasional copy of _exactly_ what we were
given, but the GNU terms can be interpreted as requiring us to give away
all the Quintus Prolog sources if we ever distribute GNU Emacs code that
*we* have changed. (The whole point of an editor interface like this is
to produce the illusion of a single program, after all.) There are a lot
of nice things you can say about GNU Emacs, but "it encourages companies
to develop supported products based on it" is by Stallman's careful choice
not one of them.
------------------------------
Date: 8 Jun 88 13:04:40 GMT
From: bunny!bs30@husc6.harvard.edu (Bernard Silver)
Subject: GNU vrs UNIPRESS
In article <500@expya.UUCP> jtr@exsb.cs.exeter.ac.uk (Jason Trenouth) writes:
>Then the department began using the Sun-interfaced GNU Emacs and my troubles
>were over. Yessiree, I'm a BORN AGAIN GNU lover.
>
>CONS:
>
>
> No find definition power (Ouch this hurts!), and not linked to
> debugger.
It is fairly easy to make a find_definition function for emacs.
You have to load an extra predicate into your prolog code but thats OK.
Note that
find_pred(Pred,Arity) :-
current_predicate(Pred,Skel),
functor(Skel,Pred,Arity),
!,
source_file(Skel,FileName)
<Stuff ommited here>
locates the file that pred is in (if it exists). The rest of the definition
writes out the relevant commands for gnu to find that file and
search for the predicate. These commands are written in a temp file that
GNU automatically loads when the find definition command is issued. It works
fine. If current_predicate fails, a GNU error message is written to the temp
file.
Compiling regions does have the problem that you mentioned (that GNU
believes it comes from a different file) but this really isn't too
much of a hassle. ( I turn the error detection off automatically when
compiling regions. If Prolog complains when I load in the file
(predicate previously defined in user) I can safely ignore this)
-- Bernard
------------------------------
Date: 13 Jun 88 14:53:56 GMT
From: macbeth!dowding@burdvax.prc.unisys.com (John Dowding)
Subject: GNU vrs UNIPRESS
In article <114@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>*we* have changed. (The whole point of an editor interface like this is
>to produce the illusion of a single program, after all.) There are a lot
Although I would normally hate to nit-pick a (parenthetical) comment,
I have to make an exception in this case. I dont think that you want the
emacs interface to produce the illusion of a single program at all.
In the name of this illusion, the Quintus Prolog emacs interface has
the following "features":
- You cannot start Prolog w/ interface if you are already in emacs.
Prolog can only be called from the (in our case) unix prompt.
- Many nice, handy emacs features have either been deformed or
destroyed. These include delete-window (why *cant* I take the
prolog buffer off the screen for a while. I know how to get
it back), and shell (in our version, you couldnt run any other
subprocess besides prolog, not even a clock).
Besides this, because the prolog/emacs interface was a separate
environment, Quintus felt free to make arbitrary changes to the
default key bindings that had nothing to do with prolog.
These include the kill-ring commands, and incremental search.
-- John Dowding
------------------------------
Date: 14 Jun 88 04:53:25 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Subject: GNU v. UNIPRESS
In article <6604@burdvax.PRC.Unisys.COM> dowding@macbeth.PRC.Unisys.COM
(John Dowding) writes:
>In article <114@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>>(The whole point of an editor interface like this is
>>to produce the illusion of a single program, after all.)
>
>Although I would normally hate to nit-pick a (parenthetical) comment,
>I have to make an exception in this case. I dont think that you want the
>emacs interface to produce the illusion of a single program at all.
>In the name of this illusion, the Quintus Prolog emacs interface has
>the following "features":
[specific criticisms deleted]
There are two separate and distinct questions:
(1) whether an editor interface should present the illusion of a single program
(2) what changes to an editor are permissible/desirable in the name of
simplifying a particular interface.
The points that Dowding criticised are all related to question (2), not
to question (1). The changed key bindings are not at all "in the name
of this illusion", they are all things that the designers of that part
of the system thought were desirable whatever the interface looked like.
With respect to question (1), does anyone think it would be a _good_ thing
for Prolog and Emacs to have a different notion of what the current directory
is? Or of what the current state of a file is?
By the way, if you are using Quintus Prolog and have comments about our
editor interface (or anything else), **please** send them to our
Technical Support people. The editor interface is not cast in concrete,
but if nobody complains to us we think it doesn't need changing.
--------------------------------
End of PROLOG Digest∧↓∀εMODERN!↓P↓5α↓/z↓1λβz:
∂10-Jul-88 0605 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #42
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Jul 88 05:46:54 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA28885; Sun, 10 Jul 88 02:10:53 PDT
Date: Sun, 10 Jul 88 02:10:53 PDT
From: Chuck Restivo <restivo@polya.Stanford.EDU>
Message-Id: <8807100910.AA28885@polya.Stanford.EDU>
To: restivo@polya.Stanford.EDU
Subject: PROLOG DIGEST V6 #42
Date: Sunday, 10 July 1988 02:53-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@POLYA.STANFORD.EDU>
Reply-to: PROLOG@POLYA.STANFORD.EDU>
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #42
To: PROLOG@POLYA.STANFORD.EDU
PROLOG Digest Sunday, 10 July 1988 Volume 6 : Issue 42
Today's Topics:
Query - Call/1,
Implementation - KR,
LP Library - Book Review
-----------------------------------------------------------------------------------------------------------------------------
Date: 7 Jun 88 02:31:00 GMT
From: uicsrd.csrd.uiuc.edu!sehr@uxc.cso.uiuc.edu
Subject: Call/1 and goal processing
I am in the process of writing an Or-parallel interpreter for Prolog,
and have run across a difficulty. The question I wonder about is how
other interpreters that use a structure-shared representation go about
implementing call/1 in an efficient manner without unduly penalizing
ordinary goal processing. It seems that if one allows the interpretation
of dynamically constructed goals (i.e. those constructed via functor/3,
arg/3, and univ (=..)), then one must cope with the possibility of
variable dereferencing during the selection of a goal to process. Does
anyone out there know how it is done in other interpreters (C-Prolog,
SB-Prolog, etc.)?
-- David
------------------------------
Date: 15 Jun 88 19:41:11 GMT
From: quintus!ok@unix.sri.com
Subject: Knowledge representation and Prolog
This is a forwarded message.
In the future, I suggest that instead of sending things to me for
forwarding, people should send mail to the Prolog Digest at
Prolog@Polya.Stanford.EDU
FORWARDED MESSAGE:
Does anyone know of any KRL written in Prolog besides APES? Has anyone any
comments on attempts to mimic KEE or ART type systems in Prolog?
Jerry Harper: Merrion Gates Software, Rosemount Court, Booterstown Avenue,
: Co Dublin, IRELAND
jharper@euroies.uucp
------------------------------
Date: 16 Jun 88 18:13:38 GMT
From: antares!finin@burdvax.prc.unisys.com (Tim Finin)
Subject: Knowledge representation and Prolog
We here at the Unisys Paoli Research Center have been using KNET, a
Knowledge Represention system implemented in Prolog, on a number of AI
projects since about 1982. Attached is a brief description of KNET.
More details can be found in an article which will appear in a
forthcoming issue of the Journal of Logic Programming. Tim
KNET is a frame-based knowledge representation system developed at the
Unisys Paoli Research Center to support the acquisition and
maintenance of large, real-world knowledge bases. The KNET system is
currently being used in a rule-based diagnosis and maintenance system
(KSTAMP), in a model-driven configuration expert system (BEACON) and
in our natural language processing system (PUNDIT).
The KNET representation language is similar to KL-ONE in that it is
based on a formal semantic model which defines the meaning of objects
in its knowledge bases. Objects in the knowledge base are called
concepts, each of which has a unique name. A KNET knowledge structure
consists of a number of concepts organized into two distinct data
structures, called hierarchies. Each hierarchy has its own structure,
but the two are related in a complex manner.
The first hierarchy is the specialization hierarchy. Concept B is
said to specialize concept A if B is a kind of A. There is a single
designated root concept, and all concepts participate in the
specialization hierarchy. It is essentially the IS-A hierarchy used
as a basis of conventional semantic networks. It is used so that
components (see below) may be described at a single concept and
inherited by all the children of that concept. The specialization
hierarchy is more general than the conventional IS-A network in that
it is possible for a concept to specialize more than one other
concept, thus inheriting properties from all its parents. This
feature is termed multiple inheritance.
The second hierarchy is the aggregation hierarchy. In this hierarchy,
the children of a concept are its components, and taken as an
aggregate they completely define that concept. In some cases these
children are not components in a literal sense, but are properties, as
for example the wall voltage required by a device may be a property of
that device. A link in this hierarchy consists of an object called a
role which names the component, together with a connection to the
owner of the role and another connection to the type of the role
(which is another concept).
The final constituent of a KNET structure is the constraint. A
constraint is a piece of executable code attached to the network. The
code is available for use by a program using KNET (an application);
whether, when, and how it is used is up to the application. A
constraint is housed at some particular concept, and refers to one or
more roles. Exactly one of the roles referred to by a constraint is
designated as the trigger of the constraint; the remaining roles are
the targets of the constraint. The purpose of the trigger is to
provide a means for indicating within the KNET structure when an
application program should use a constraint. The meaning of a
constraint is always defined relative to the context in which the
constraint occurs. This means that references to roles made from
within an inherited constraint always refer to the local context
rather than to the context in which the constraint was originally
defined.
Finally, it is important to maintain consistency in knowledge
networks. The definition of consistency varies for differing kinds of
knowledge representation, and depends on the semantic model
implemented by the knowledge representation. For KNET, a fundamental
consistency requirement is the subsumption requirement, defined as
follows: If concept A has a role R with type B, and if concept A2
specializes A, then the type of the inherited role R2 must be B or a
specialization of (a specialization of ...) B. If this requirement is
not met, a subsumption violation is said to occur. The program which
builds KNET structures, the Browser/Editor, automatically checks for
and disallows subsumption violations and several other types of
inconsistencies.
KNET has been implemented in a standard subset of Prolog which has
allowed it to be ported to several different Prolog systems on a
variety of machines. Versions of KNET run on VAXes, Suns, Lisp
machines and PCs. An interactive browser/editor system for KNET
knowledge bases can use a simple ASCII terminal interface, enabling
its use on each of these machines. A more sophisticated graphical
browser/editor is available for use on Sun workstations.
-- Tim Finin
------------------------------
Date: 17 Jun 88 02:44:14 GMT
From: shardy@teknowledge-vaxc.arpa (Steve Hardy)
Subject: Knowledge representation and Prolog
Jerry Harper asks about knwoledge representation languages
written in Prolog (besides APES.)
Teknowledge developed a prolog-based expert system shell called
M.1. It was released in June 1984 and has sold close to 4,000
copies.
M.1 is unusual in that it is a complete logic programming
language as well as being an easy-to-use expert system shell.
For example:
/* --- simple EMYCIN-like heuristic rule --- */
if main-component-of-meal = beef
then best-color-of-wine = red cf 75.
/* --- list processing --- */
infix <>. /* for "append" */
[] <> LIST = LIST.
if LIST1 <> LIST2 = LIST3
then [ITEM|LIST1] <> LIST2 = [ITEM|LIST3].
/* --- objects and inheritance --- */
issquare(obj-22).
size(obj-22) = 5.
if isrectangle(X) and
height(X) = H and width(X) = W and H * W = R
then area(X) = R.
if issquare(X) then isrectangle(X).
if issquare(X) and size(X) = S then height(X) = S.
if issquare(X) and size(X) = S then width(X) = S.
After releasing four versions of M.1 in Prolog, Teknowledge
recoded the system in C. This led to the system being
approximately five times faster and able to handle knowledge
systems five times larger (up to 2000 rules on a 640K IBM-PC.)
It was easier to work out the design of M.1 with Prolog than it
would have been with C.
-- Steve Hardy
------------------------------
Date: 1 Jul 88 01:15:52 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Subject: An example from "Knowledge Systems & Prolog"
Yesterday I bought a copy of
[A Logical Approach to Expert Systems and Natural Language Processing]
Knowledge Systems and Prolog
Adrian Walker, Michael McCord, John Sowa, & Walter Wilson
Addison-Wesley 1987
ISBN 0-201-09044-9
I haven't had time to read much of it yet.
There's some rather good advice in it, and it is easily the most
powerful argument I have ever seen for Edinburgh syntax.
For now I'd just like to comment on one particular example, found
found on page 413. I'll transliterate it into Edinburgh syntax.
% most_general_terms(Terms, GeneralTerms)
% is true when GeneralTerms is the set of terms in Terms which are
% subsumed by no other term in Terms.
most_general_terms(Terms, GeneralTerms) :-
qsort(Terms, TermsInOrder),
most_general_terms_in_order(TermsInOrder, GeneralTerms).
% most_general_terms_in_order(TermsInOrder, GeneralTerms)
% is just like most_general_terms/2, except that less general terms
% precede more general terms in TermsInOrder (that is, if X and Y
% are both in TermsInOrder and X subsumes Y, X must follow Y). The
% order of terms in the result is the same as the order in the input.
most_general_terms_in_order([], []).
most_general_terms_in_order([Term|Terms], GeneralTerms) :-
member(MoreGeneral, Terms),
subsumes(MoreGeneral, Term),
!,
most_general_terms_in_order(Terms, GeneralTerms).
most_general_terms_in_order([Term|Terms], [Term|GeneralTerms]) :-
most_general_terms_in_order(Terms, GeneralTerms).
% This version of quicksort is supposed to order its input so that
% if X and Y are both given and X subsumes Y, X will follow Y in
% the output.
qsort(Terms, TermsInOrder) :-
qsort(Terms, TermsInOrder, []).
qsort([], L, L).
qsort([Term|Terms], L0, L) :-
partition(Terms, Term, Before, After),
qsort(Before, L0, [Term|L1]),
qsort(After, L1, L).
partition([], _, [], []).
partition([Term|Terms], Pivot, Before, [Term|After]) :-
subsumes(Term, Pivot),
!,
partition(Terms, Pivot, Before, After).
partition([Term|Terms], Pivot, [Term|Before], After) :-
partition(Terms, Pivot, Before, After).
%---- end of first version
Now, my antipathy to (falsely so-called) "quicksort" is well known by now.
But in this case its quadratic worst case hardly matters, because if there
are N terms initially, most_general_terms_in_order/2 will do O(N**2) calls
to subsumes/2 anyway. So we might as well do
most_general_terms(Terms, GeneralTerms) :-
most_general_terms(Terms, [], GeneralTerms).
% At each call of most_general_terms(T, G, X)
% there is a list L such that append(L, T, Terms) and
% most_general_terms(L, G).
most_general_terms([], GeneralTerms, GeneralTerms).
most_general_terms([Term|Terms], GeneralTerms0, GeneralTerms) :-
knock_out(GeneralTerms0, Term, GeneralTerms1),
most_general_terms(Terms, GeneralTerms1, GeneralTerms).
knock_out([], Pivot, [Pivot]).
knock_out([Term|Terms], Pivot, GeneralTerms) :-
subsumes(Pivot, Term),
!,
knock_out(Terms, Pivot, GeneralTerms).
knock_out([Term|Terms], Pivot, [Term|Terms]) :-
subsumes(Term, Pivot),
!.
knock_out([Term|Terms], Pivot, [Term|GeneralTerms]) :-
knock_out(Terms, Pivot, GeneralTerms).
%---- end of second version
This has the nice property that the order of terms in GeneralTerms is
exactly the same as the order of terms in the original Terms list,
apart from the deletion of subsumed terms. It does at most N(N-1)
calls to subsumes/2, and while the version of Walker et alia does
at most (1/2)N(N-1) such calls in most_general_terms_in_order/2,
it may do a similar number in partition/4. Indeed, because subsumes/2
is a partial order (not a total order), it is likely to fail rather more
often than it succeeds, so partition/4 is likely to put most of its
first argument into the Before list, and quadratic behaviour is very
likely. (In fact, whenever subsumes(Term, Pivot) succeeds, that tells
us that Pivot will not be in the final result, so we might as well drop
it.)
Actual measurements show that the two versions do about the same number
of calls to subsumes/2: both tend to be close to N(N-1) calls. Sometimes
the "unsorted" method does much better than the "sorted" one, sometimes it
does a little worse.
This is actually a very interesting problem. It crops up in all sorts of
guises. I currently have an algorithm which does at most N(N-1) calls to
subsumes/2 and reduces to at most 2(N-1) when subsumes/2 happens to be
total. If anyone knows of a better algorithm I would be _very_ interested
to hear of it.
------------------------------
Date: Fri, 1 Jul 88 17:30:43 PDT
From: quintus!ok@Sun.COM (Richard A. O'Keefe)
Subject: "Knowledge Systems in Prolog", more examples
Well, I've read more of the Walker, McCord, Sowa, & Wilson book,
and while I still say that there is some good advice in it, there are
one or two things it would pay you *NOT* to imitate.
(1) Wrappers.
On pp 34-35, we are told that the Pascal declaration
type person =
record
name : string;
address : string;
date_of_birth : array [1..3] of integer;
sex : boolean;
end {record};
-- which, by the way, is not a brilliant piece of Pascal --
introduces a type instances of which have as Prolog equivalents
terms of the form
person(name(N), address(A), date_of_birth(D.M.Y), sex(S))
Again, on page 51 we are shown
/* Prolog structure */ { Pascal record }
type loc =
loc( record
farmer(F), farmer : string;
wolf(W), wolf : string;
goat(G), goat : string;
cabbage(C) cabbage : string;
) end {record};
-- which, in context, is an amazingly bad piece of Pascal --
DON'T *DO* THIS! Supposing F, W, G, and C to be constants,
the representation they recommand would cost 13 words in Quintus
Prolog (18 words in another Prolog I know of), whereas the
sum-of-products approach yields the *real* equivalent of the
Pascal record as
loc(Farmer, Wolf, Goat, Cabbage)
at a cost of 5 words in Quintus Prolog (6 in another Prolog).
That's a substantial waste of space and time, and worse still,
it confuses the reader, because when you see patterns like
loc(farmer(F),_,_,_)
and loc(_,wolf(W),_,_)
floating around, your natural assumption is that patterns like
loc(wolf(W),_,_,_) and loc(_,farmer(_),_,_) may be possible, for
why else would anyone have unary wrappers if not to distinguish
such cases?
(2) Over-use of "."
At least in chapter 2, the book has an excessive fondness for ".".
Consider the birth_date(Day.Month.Year) example above. This would
be better as date(Year,Month,Day) --when, amongst other advantages,
it will sort properly-- at a space cost of 4 cells, which is
admittedly the same as the cost of Day.Month.Year. The big
advantage here is that all things made out of dots look alike, so it
is very hard for a human reader to tell D.M.Y from any other X.Y.X,
but date(Y,M,D) proclaims its nature to the world. On page 55, this
book actually _recommends_ X.Y, X.Y.Z and the like, so this was not
an accidental slip but a matter of policy.
The authors have finally cured me of my lingering fondness for infix dot.
I am now thoroughly convinced that bracket notation is to be preferred.
Perhaps if I had been reading Lee Naish's code I might have been swayed
the other way, but I fear that he may not be typical.
(3) Factorial
On page 36 they present the following code:
factorial(0,1).
factorial(N,X) <- lt(N,0) &
write('Negative input to factorial').
factorial(N,X) <- (M := N - 1) & factorial(M,Y) &
(X := N * Y).
{Note: * in VM/Prolog is usually an anonymous variable, but not here.}
What's wrong with this? Well, according to this, factorial(-1, 472)
is true. {For the benefit of those fortunate enough not to have
VM/Prolog, try
factorial(0, 1).
factorial(N, X) :-
N < 0,
write('Negative input to factorial.'), nl.
factorial(N, X) :-
M is N-1,
factorial(M, Y),
X is N*Y.
} For real fun, try factorial(1, 2). If you are going to print an
error message like this, you should at least have the decency to fail.
So the second clause would have been better as
factorial(N, *) <- lt(N,0) &
write('Negative input to factorial') & / & fail.
(4) (falsely so-called) "quick" sort
Section 2.4.1 (p89) starts out admirably, saying that "The choice of
algorithm is the most important factor in determining performance".
But the example they consider is sorting, and they say "Three
different algorithms might be considered:
- a permutation sort that tries all possible permutations of a
list in order to find one that is sorted
- a bubble sort that interchanges pairs of elements until the
result is sorted
- a version of Quicksort ..."
I am really getting thoroughly sick of "quick" sort. Remember, if you
check the fine print in Knuth, Sedgewick, Melhorn, or any good book
on the subject, you will find that the average case of "quick" sort
does about 1.4 times as many comparisons as the WORST case of merge sort.
If people are going to presume to give advice about sorting, they might
at least check the standard literature. (Not that sorting is a major
topic in Walker et al, but it wasn't a major topic in Clocksin&Mellish
either, and that didn't stop people mistaking the difference-list
example for advice about how to sort.)
(5) Breadth-first search.
On pp 82-83 we find
breadth_first(Goal, Histories, Answer) <-
member(Goal.Past, Histories) &
reverse(Goal.Past, Answer).
breadth_first(Goal, Histories, Answer) <-
Histories=(*,*) &
set_of(Next.Current.Past,
member(Current.Past, Histories) &
move(Current,Next) & \member(Next,Past),
New_history_list) &
remove_duplicate_head(New_history_list, Clean_list) &
breadth_first(Goal, Clean_list, Answer).
remove_duplicate_head(F.S.Tail, Clean) <-
((F=(Head.*) & S=(Head.*)) ->
remove_duplicate_head(F.Tail,Clean);
(remove_duplicate_head(S.Tail,L) &
Clean=(F.L))).
remove_duplicate_head(F.nil, F.nil).
remove_duplicate_head(nil, nil).
Let's start with remove_duplicate_head. The input is a list of lists,
which is sorted, and subsequences ...,[A|T1],...,[A|Tn],... with the
same head (A) are to be replaced by the first member of the subsequence
(here [A|T1]). Can we do this more cleanly?
remove_duplicate_heads([], []).
remove_duplicate_heads([[Tag|Info]|Given], [[Tag|Info]|Clean]) :-
skip_duplicate_heads(Given, Tag, Clean).
skip_duplicate_heads([[Tag|_]|Given], Tag, Clean) :- !,
skip_duplicate_heads(Given, Tag, Clean).
skip_duplicate_heads(Given, _, Clean) :-
remove_duplicate_heads(Given, Clean).
In Quintus Prolog, the cleaner version is about three times faster.
I think the test \member(Next, Past) might perhaps be better as
\member(Next, Current.Past), in case the problem graph has self-loops.
If you are given a generation function which yields all of the children
of a node at once instead of a move/2 which enumerates them, you can
write breadth first search without appealing to set_of/3 at all.
{The predicate called set_of/3 in this book corresponds to the
predicate called set_of_all/3 in the Quintus library, not to the
predicate called set_of/3, except that set_of_all/3 checks that it
is being called soundly, and set_of/3 in this book doesn't.}
Reminder:
In this note I've concentrated on some of the infelicities in the book.
I repeat that there is a lot of good stuff in it, and on the whole I do
not regret its purchase.
------------------------------
Date: Sat, 2 Jul 88 22:03:31 PDT
From: quintus!ok@Sun.COM (Richard A. O'Keefe)
Subject: "Knowledge Systems and Prolog", chapter 3
Yes, it's me again, with yet a third set of comments on the
"Knowledge Systems and Prolog" book by Walker, McCord, Sowa, & Wilson.
This particular set of comments pertains to chapter 3. I hasten to
say at the outset that there is a lot of good stuff in this chapter
which I wish I had written myself, but of course I have nothing to
say about _that_.
1. Logic Programming Development Process (pp 110-111)
Don't take steps 1..9 too seriously; that's not how I do it, and
one of the most important steps has been omitted, namely "check to
see if someone else has already solved the problem". But the rest
of the advice on p111 is good.
2. Reading (p 113)
The book presents two fragments (recast here as Prolog):
...
read(Stream1, X),
read(Stream2, T),
process(X, T)
...
and
...
customer(Name),
catalogue_item(Item),
interested_in(Name, Item),
send_letter(Name, Item)
saying "For example, catalogue_item/1 may simply read the next term".
Now the second fragment looks as though it has a declarative reading.
But its behaviour is radically different from the behaviour which
would result if customer/1 and catalogue_item/1 were tables. It is
_NOT_ good style to give commands with side effects names which suggests
that they are pure relations. In fact it is very bad style. Suppose
we had the customer and catalogue_item tables in memory as pure
relations, and wrote this failure-driven loop:
send_letters :-
customer(Customer),
catalogue_item(Item),
interested_in(Customer, Item),
send_letter(Customer, Item),
fail
; true.
This would combine *every* Customer with *every* catalogue Item.
But the original fragment with the two read commands doesn't do that;
it reads an X and a T and combines _that_ X with _that_ T and no other.
By the way, you _can_ keep (a small number of) tables in files and
access them with read/1. Here's an example (using Quintus Prolog):
:- dynamic
table_stream/2.
initial_position('$stream_position'(0,1,0)).
read_from_external_relation_1(Table, Entry) :-
( table_stream(Table, Stream) -> true
; external_relation(Table, FileName),
open(FileName, read, Stream),
assert(table_stream(Table, Stream))
),
initial_position(Zero),
do_external_access(Zero, Stream, Entry).
do_external_access(Before, Stream, Entry) :-
stream_position(Stream, _, Before),
read(Stream, Term),
stream_position(Stream, After),
( Term == end_of_file -> fail
; Entry = Term
; do_external_access(After, Stream, Entry)
).
external_relation(customer, 'custom.dat').
external_relation(catalogue_item, 'catalo.dat').
customer(Customer) :-
read_from_external_relation_1(customer, Customer).
catalogue_item(Item) :-
read_from_external_relation_1(catalogue_item, Item).
Now, this _is_ a version of catalogue_item/1 which "simply read[s]
the next term", but it is pretty remote from the first fragement.
I don't know whether Frank McCabe invented this technique, but he's
the one I got it from (testing the code above was the first time I
have ever _used_ the technique, mind...).
If you can possibly fit the information into memory, _do_ it.
Don't keep reading it from a file over and over again. Another
possibility, instead of using read_from_external_relation_1/2,
would be to read a file once and build an index in memory, so
that fewer reads would be done.
For example, suppose we have a a file 'passwd.pl' containing items like
passwd(teksup,123,45,'Tech Support', '/peano/teksup','/bin/csh').
passwd(halt, 6, 7,'Stop Machines', '/', '/etc/halt').
passwd(ok, 89,10,'Richard A. O''Keefe','/dedekind/ok', '/bin/csh').
{Crackers beware: these are _not_ real Quintus /etc/passwd entries!}
We might do this:
:- dynamic
passwd_stream/1,
passwd_index/2.
initialise_passwd(Stream) :-
open('passwd.pl', read, Stream),
assert(passwd_stream(Stream)),
repeat,
stream_position(Stream, Position),
read(Stream, Term),
( Term = passwd(Key,_,_,_,_,_) ->
assert(passwd_index(Key, Position)),
fail
; true
),
!. % The Stream is left open!
passwd1(Key, Uid, Gid, Name, Home, Shell) :-
( passwd_stream(Stream) -> true
; initialise_passwd(Stream)
),
passwd_index(Key, Position),
stream_position(Stream, _, Position),
read(Stream, passwd(Key,Uid,Gid,Name,Home,Shell)).
It is fair to give a predicate so defined a name which suggests
that it is a pure table, because (apart from tying up a stream and
being rather slow) that's how it _acts_.
ONLY use this technique if you can build a good index; it can be
hundreds, even thousands, of times slower than accessing tables in
main memory.
3. Wrappers (page 114-115)
There is an example on pp 114-115 which reads thus:
name(Name, TelephoneNumber, File) :-
get_next_record(File, Record),
parse_record(Record, name(Name,TelephoneNumber)).
↑↑↑↑↑ ↑
parse_record(Record, name(Name,TelephoneNumber)) :-
↑↑↑↑↑ ↑
parse_name(Name, Record, Rest_of_record),
parse_blanks(_, Rest_of_record, Last_of_record),
parse_telephone(TelephoneNumber, Last_of_record, _).
{If you look at the code in the book, you'll see that the first
argument of parse_blanks/3 is an anonymous variable in all calls
and definitions, so it might as well not be there.}
There is much to quarrel with in the choice of names here:
the parse_*** predicates are genuinely relational, so should have
noun-phrase or adjective-phrase names, not names that look like
commands. Worst of all, the operation which _is_ a command (that
is, which has a side effect) is given the name name/3 which looks
like a pure relation. It would be better named e.g.
read_name_and_phone_number(File, Name, PhoneNumber)
My main point here is that name(_,_) is a useless wrapper. If the
name and phone number had to be returned to the caller so packaged,
there'd be some sense in it, but not here. It would be better as
read_name_and_phone_number(Stream, Name, PhoneNumber) :-
get_line(Stream, Chars),
name_and_phone_number(Name, PhoneNumber, Chars, _).
name_and_phone_number(Name, Exchange-Extension) -->
token(Name),
blanks,
number(Exchange), "-", number(Extension).
where the compound term -(_,_) here _is_ justified because that's
what the caller wants.
4. Query-the-user (pp 116-117, p120).
When you hit page 116, look ahead to page 120. I'll not comment on
the rather major problems of the code on page 116, because the code
on page 120 remedies some of them.
The idea is that you want a relation user('User''s first name')
-- by the way, I find it offensive to have computers address me by
my first name, so whenever a program asks me my first name I lie;
my computer account name will do fine for any genuine identification--
but you don't want to ask unless you turn out to need the information.
The code on page 120 is (converted to Quintus Prolog):
:- dynamic
known/1.
user(Name) :-
known(user(Name)),
!.
user(Name) :-
prompted_line('What is your first name? ', Chars),
( verify(Chars) -> % you have to supply verify/1
atom_chars(Name, Chars),
assert(known(user(Name)))
; format('~s: not verified.~n', [Chars]),
user(Name)
).
{This is not identical to the code in the book, but it has the same
kinds of bugs, which is what I'm concerned with.}
I loaded this into Quintus Prolog, together with library(prompt)
and this definition of verify/1:
verify([_,_]).
Now see what happens:
| ?- user(fred).
What is your first name? jim
jim: not verified. % right
What is your first name? ok
no % right, BUT
| ?- listing(known/1). % prints _nothing_
| ?- user(Who). % should pick up 'ok', BUT
What is your first name? ok % it asks AGAIN!
Who = ok % but that's not all...
| ?- user(dz).
What is your first name? ok % it asks yet AGAIN!
no
The code breaks down in (at least) two ways:
A) If we call it with Name bound when known(user(X)) is true--i.e.
the user has been asked for his name--but X\==Name, the user
will be asked for his name again. Fortunately, the _second_
breakdown then occurs, so at least it isn't _stored_ again.
B) If we call it with Name bound when the user name is not known
(or when it is known to be different from Name), we'll ask for
the name, verify it, and then fail before storing the name.
How should it be written?
:- dynamic
property_known/2.
property_type(user, atom).
...
property_prompt(user, 'What is your first name? ').
...
property_verify(user, Chars) :-
verify_user(Chars).
...
simple_query(Property, Value) :-
simple_query_1(Property, X),
Value = X.
simple_query_1(Property, Value) :-
property_known(Property, Value),
!.
simple_query_1(Property, Value) :-
property_type(Property, Type),
simple_query_1(Type, Property, Value),
assert(property_known(Property, Value)).
...
simple_query_1(atom, Property, Value) :-
property_prompt(Property, Prompt),
repeat,
prompted_line(Prompt, Chars),
( property_verify(Property, Chars)
; format('~s: not verified~n', [Chars]), fail
),
!,
atom_chars(Value, Chars).
...
user(UserName) :-
simple_query(user, UserName).
Now, with this definition, we get
| ?- user(fred).
What is your first name? jim
jim: not verified
What is your first name? ok
no
| ?- listing(property_known/2).
property_known(user,ok).
yes
| ?- user(Who).
Who = ok
| ?- user(dz).
no
which is what you would expect something like this to do.
5. "Global variables" (p122)
I have to quote their VM/Prolog code here, because delax/1 doesn't
behave quite like retract/1, more like retract_first/1.
A ::= B <-
try(delax(global_value(A, *))) &
addax(global_value(A, B)).
try(X) <- X.
try(*).
What's wrong with this? Well, after converting to Quintus Prolog,
I got the following result:
| ?- x ::= 1, listing(global_value/2).
global_value(x,1).
| ?- x ::= 2, global_value(x, 1).
no
| ?- listing(global_value/2).
global_value(x, 2).
global_value(x, 2).
I'll leave you to figure _that_ one out for yourselves, but the
moral is that any time the last clause of a predicate is a
catch-all case like the last clause of try/1, the chances are
someone is trying to be clever and failing.
6. Another steadfastness problem (p122)
We are told on page 122 that "the global_value/2 technique
described above can be used to simulate a stack, as follows:
push(Stack, Item) <-
addax(global_value(Stack, Item), 0). % "asserta"
pop(Stack, Item) <-
delax(global_value(Stack, Item)).
The predicates push/2 and pop/2 have their obvious meaning."
Actually, they haven't. Or at any rate pop/2 hasn't. If pop/2
succeeds, it did delete an item from the stack, but the item it
deleted may not have been at the top of the stack... Working
Prolog code is
push(Stack, Item) :-
asserta(global_value(Stack,Item)).
pop(Stack, Item) :-
retract(global_value(Stack,Top)),
!,
Item = Top.
top(Stack, Item) :-
global_value(Stack, Top),
!,
Item = Top.
TO BE CONTINUED
I have about as much more to add, but it's time to go home.
DISCLAIMER
Remember, I'm criticising slips in a by-and-large-reasonable book;
the good stuff can speak for itself.
You'll recall that I had very little to criticise in the _content_
of the Warren & Maier book, but raged about the misleading preface
and blurb. I recommended it to the Prolog class I taught last week,
and if I had bought the Walker et al book by then I'd probably have
suggested it to them as worth reading too. Yes, I've made up my
mind, I _shall_ recommend it to the next Quintus class, if only to
show them why they should buy QP370 rather than VM/Prolog (:-).
---------------------------------
End of PROLOG Digest
∂10-Jul-88 0942 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #43
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Jul 88 09:41:53 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA26425; Sun, 10 Jul 88 07:58:53 PDT
Date: Sun, 10 Jul 88 07:58:53 PDT
From: Chuck Restivo <restivo@polya.Stanford.EDU>
Message-Id: <8807101458.AA26425@polya.Stanford.EDU>
To: restivo@polya.Stanford.EDU
Subject: PROLOG DIGEST V6 #43
Date: Sunday, 10 July 1988 02:53-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@POLYA.STANFORD.EDU>
Reply-to: PROLOG@POLYA.STANFORD.EDU>
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #43
To: PROLOG@POLYA.STANFORD.EDU
PROLOG Digest Sunday, 10 July 1988 Volume 6 : Issue 43
Today's Topics:
Query - Unification & Arrays,
Announcement - Association For Logic Programming,
Implementation - Trilogy
-------------------------------------------------------------------------------------------------------------------------------
Date: 15 Jun 88 15:43:25 GMT
From: bungia!com50!ems!srcsip!kan@UMN-CS.ARPA (Ling Kan)
Subject: Unification Algorithm
In "An Efficient Unification Algorithm" by Alberto Martelli and Ugo Montanari
ACM TOPLS Vol. 4, No. 2 1982, the authors described an unification algorithm
that has occur check built-in and also has a better performance than Huet's and
Paterson and Wegman's method.
Does anyone know that if this algorithm is used in any Prolog system? Is in
reality this algorithm is as good as the authors claimed? And how about the
implementation cost of this method? Is there any other unification algorithm
has a better performance?
Thank you.
-- Ling Kan
------------------------------
Date: 27 Jun 88 17:18:57 GMT
From: mnetor!utzoo!utgpu!utcsri!qucis!feret@uunet.uu.net (Michel Feret)
Subject: Arrays In Logic Programming
I'm currently working on an implementation of a Resolution theorem
prover written in Nial (Nested Interactive Array Language) . Nial uses
nested multi-dimensional collections of basic objects (integers, truth
values, complex numbers, ...) called nested arrays. We are using these
arrays as logical terms in the logic programming component of Nial .
I'm looking for theorem provers using more complex data structures
than lists, and being able to perform unification over these data structures.
Any references, pointers, addresses will be welcomed.
-- Michel Feret.
------------------------------
Date: 22 Jun 88 16:36:34 GMT
From: necntc!drilex!axiom!linus!pc@ames.arc.nasa.gov (Melissa P. Chase)
Subject: Association for Logic Programming
I'm sorry that it has taken so long to post the information about the
Association for Logic Programming, but here it is:
From: Andy Cheese <abc%computer-science.nottingham.ac.uk@NSS.Cs.Ucl.AC.UK>
The Association For Logic Programming
Membership Fees are 25 dollars for a full member and 15 dollars for a
full time student.
1988 subscription fees for the Journal of Logic Programming are 38
dollars for USA and Canada and 54 dollars for the rest of the world.
contact address is :
Miss Cheryl Anderson
The Association for Logic Programming
Department of Computing
Imperial College
180 Queen's Gate
London
SW7 2BZ England
After I received this reply, I received the mailing for LP '88
which includes an ALP membership form that you can send in with
the conference registration form. According to this form, benefits of
ALP membership include:
- Affiliation with the principal international association in
the field of logic programming
- Reduced registration fees for ALP-sponsored conferences
- Subscription to the Logic Programming Newsletter
- Early announcements of ALP-sponsored activities.
- A reduced subscription rate for individuals to Jour. Logic. Prog.
------------------------------
Date: 1 Jul 88 15:56:48 GMT
From: ubc-cs!faculty.cs.ubc.ca!voda@beaver.cs.washington.edu (Paul Voda)
Subject: How Prolog logic programmers see Trilogy
The reason I am writing this note is that the programming language Trilogy
I have designed and implemented as an answer to the extra-logical features
of supposedly declarative Prolog as well as to it's appalling inefficiency
in the deterministic (procedural) situtations (see the Ross Overbeek's theorem
prover benchmark) is being misrepresented by some very influential protagonists
of logic programming.
For almost a year now I have been presenting Trilogy as a logic programming
language with built-in costraints (Presburger arithmetic, array constraints,
etc.). I was always stressing that Trilogy is a language based on logic, i.e.
on the first order theory of pairs. The variables in Trilogy's programs range
over pairs (i.e. over S-expressions of Lisp). Trilogy does
not use Horn clauses, its predicates have the form of iff conditions (similar
to the completed form of Prolog predicates).
Moreover, the computation of Trilogy programs does not have to be explained
by the unification. This is because Trilogy constraints include the equality
over the domain of pairs. Instead of unifying the term a with b it is enough
to issue a constraint a = b and rely on the decision procedure
for the equality built into Trilogy.
I was also stressing that thanks to the Trilogy's modes and types
the non-backtracking (deterministic) programs can be compiled with the
efficiency of Pascal. The typing of Trilogy is quite unique in that the
type inclusion is supported and the values can be converted from one type
into another (by typing all variable to be of the universal type U of
all pairs one achieves the effect of typeless programming).
I was stating the above on various occasions and with many repetitions hoping
that people will get interested. Well many people were. On the other hand,
I was very disappointed when I have heard (and I was also told by somebody
who have heard himself) some pretty careless comments on Trilogy.
One comment came from one of the top people connected with CLP. He has publicly
dismissed Trilogy as a combination of Prolog and Ada (the emphasis was on
the lack of logic of Ada I pressume), the other public comment came from a real
authority on logic programming: Trilogy is a cross between Prolog and
Pascal (with the same implication). Such comments are very damaging
because Trilogy is quite different from Prolog, yet it is a logic
programming language. As it is I have enough difficulties presenting Trilogy
on account of the different foundations and syntax.
Needless to say the comments are absolutely unjustified and what really hurts is
that they were stated by such big authorities. As far as I know neither of the
authorities have seen Trilogy in operation and very
likely did not feel sufficiently motivated to read
thouroghly the papers I wrote on the semantic of Trilogy as well as my older
papers where I was explaining my approach to logic programming.
It is quite ironic to have Trilogy presented as the operational Pascal or Ada.
What about the extra-logical features of Prolog?
Prolog's cuts, vars, asserts, i/o, etc. are all outside of logic in the
domain of operational behavior. Actually the extra-logical features of Prolog
are much more damaging to the cause of declarative programming than the
honest non-declarativeness of Pascal. Witness how are the extra-logical "bugs"
of Prolog discussed as "meta-theoretic features" in almost all Prolog texts.
If the theoreticians can do that, the computer hobbyists are only too happy
to indulge in the "meta-programming" without seeing anything wrong about it.
One of the most horrible examples of this was in the August 1987 issue of the
Byte magazine. One enthusiast have programmed a Prolog simulation of
a microprocessor. He of course knew that the execution of a processor
instruction changes the state of the processor. Instead of parameterizing
each instruction with the old and new state he has retracted the old
state before executing an instruction and asserted it afterwards. I could
almost see him to be so proud of himself; after all he knew from the Prolog's
texts that he was doing a real meta-programming.
Trilogy was designed as a language without extralogical features. It was
implemented without any. For instance we have added to Trilogy a form of a cut
(a one solution operator) only when we have explained it logically. Even
the input/output operations and file updates are handled in Trilogy completely
within logic. Since I have supervised the implementation of Trilogy I did not
permit into the implementation a single quick implementation hack which,
although speeding up the execution, could destroy the logic.
As it happens Trilogy is the only programming language
commercially available which has both the declarative logic and sufficient
efficiency in deterministic situations.
-- Paul Voda
---------------------------------
End of PROLOG Digest
∂11-Jul-88 1443 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #44
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Jul 88 14:43:42 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA25898; Mon, 11 Jul 88 11:37:06 PDT
Date: Mon, 11 Jul 88 11:37:06 PDT
From: Chuck Restivo <restivo@polya.Stanford.EDU>
Message-Id: <8807111837.AA25898@polya.Stanford.EDU>
To: restivo@polya.Stanford.EDU
Subject: PROLOG DIGEST V6 #44
Date: Mon, 11 Jul 1988 02:53-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@POLYA.STANFORD.EDU>
Reply-to: PROLOG@POLYA.STANFORD.EDU>
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #44
To: PROLOG@POLYA.STANFORD.EDU
PROLOG Digest Monday, 11 July 1988 Volume 6 : Issue 44
Today's Topics:
Query - dBase III,
Implementation - VAX/VMS Review
------------------------------------------------------------------------------------------------------------------------------
Date: 24 Jun 88 18:29:32 GMT
From: uccba!ucqais!bbeck@tut.cis.ohio-state.edu (Bryan Beck)
Subject: Query Dbase III Plus with Turbo Prolog
I recently read an article in AI EXPERT, June 1988 written by Karl Horak about
using Turbo Prolog to query Dbase III Plus files. There were two points that
were not clearly delineated in the article, (1) How to get prolog to read the .dbf and
how to get prolog to read the .dbt files.
Also the article referencing Fileman, Rick. "Memo to Character Conversion,"
Aston-Tate Inc. TechNotes, Nov. 1987,pp 15-24.
I any one has read this article of have done anything like this, or where I can find these TechNotes. I would greatly appreciate any additional information
about trying to do this.
Thank you.
------------------------------
Date: 29 Jun 88 14:37:22 GMT
From: mcvax!ukc!dcl-cs!simon@uunet.uu.net (Simon Brooke)
Subject: Survey of Prologs for VMS VAX
About 10 days ago, I put out a message asking people to recommend PROLOGs
for VAX VMS. Many thanks to all those who replied. I'm posting (in case
anyone else is interested) what I learned. Brief word of explanation: I
was asked to select a PROLOG in which it would be possible to construct an
interface to a relational database mangement system, and the report is
heavily biased to reflect this need.
PROLOGs available for VAX/VMS:
A brief review, with regard to the needs of the Savant
project.
How systems were selected for inclusion into this report
In order to find as many VMS compatible PROLOGs as
possible, in the shortest possible time, I posted to the
USENET newsgroup comp.lang.prolog, on the basis that all
serious PROLOG developers would inevitably keep an eye on
this. This method appears to have was only partially
partially successful, in that it produced reviews of most
of the systems I was already aware of, including systems I
wasn't aware were available for VMS. However, it didn't
produce any news of systems I don't know about, and there
may still be some of those.
I also consulted the news section of the Journal 'Expert
Systems', going back two years.
What I asked for
The message which I posted asked respondents to tell me:
* What syntax it uses - especially, how like Quintus it is.
* What the 'foreign function interface' is like.
* Roughly what the performance is like.
* What the programmer's environment is like . . .
* How robust it is - and any points to watch...
* What it costs and from whom (UK supplier if possible)
The systems included
The systems which I received replies about were as follows
(in the order I received them):
Edinburgh Prolog
Quintus Prolog (two replies)
BIM_Prolog (two replies)
Poplog
On the whole, replies were directly from implementors, and,
although they may be somewhat more honest than promotional
literature, cannot be considered independent.
I also have received promotional material describing
LPA Sigma Prolog
and have found a news item describing
I/F Prolog.
Experience of the systems
I have been able to play with Quintus (on Suns under Unix),
Edinburgh (on VAX under Unix), and Poplog (on Suns under
Unix).
Quintus
This is the only one of the systems I have any significant
experience with. Quintus is a widely used - and in general
widely liked - version of a vanilla flavoured Edinburgh-
syntax PROLOG. After LISP machines, the EMACS based
development environment strikes me as so wretchedly crude
as to be almost unusable. However, by using system editors,
code can be developed reasonably quickly.
The system is relatively fast, and appears well thought out
and solid. I imagine that, on a Xerox workstation, this is
a very nice system.
Edinburgh
I have played only briefly with Edinburgh Prolog. I loaded
in the dBAccess code, most of which ran. However, the use
of the token 'not' as a negation operator is apparently not
permissible in Edinburgh prolog, and, as I did not have a
manual, I was unable to attempt to patch this.
There appears to be no compiler.
My feeling, however, is that it would be trivial to port to
Edinburgh Prolog. Whether any particular development
environment tools are supplied I can't say; but if not,
they aren't strictly needed.
Poplog
Again, I have experimented only briefly with Poplog. My
first impression was of quite remarkable slowness. Whilst
the reader of the Edinburgh system skipped over the
declarations in the (Quintus) files containing the dBAccess
code which it could not understand (because they were
Quintus specific), the Poplog reader aborted. Thus these
files could not be loaded without some editing.
Again, the syntax of 'not' differed from Quintus; in Poplog
prolog, 'not' is a one place predicate rather than a prefix
operator.
Once the files had been edited, they loaded satisfactorily,
and again, very nearly ran. Again, there appeared to be no
compiler.
Discussion
Relative performance
I don't have any good comparative figures on the relative
performance of these systems. However, what I have is as
follows:
Version KLips Hardware KLips Test Syntax Price
/Mips
Edin 2.2 VAX 750/Unix 3.66 N.Rev Edinburgh #1000
BIM 26 VAX 750/VMS 43.33 N.Rev proprietary #8150
85 Sun 3 42.5 ?? [Edin optional]
Sigma 6.9 Sun 3 3.45 ?? Lisp-based #750 [one user]
[Edin optional]
Quintus 60 Sun 3 30 N.Rev Edinburgh #4200
I/F 90 Sun 3 45 ?? Unknown #11000
40 VAX 780 ?? ??
Poplog 4.5 VAX 750 7.5 ?? Edinburgh #12000
As the Sun is rated at about 2 Mips, and the VAX 750 at
0.6 Mips, this suggests that I/F may be fastest of all,
with LPA Sigma slowest; the column KLips/Mips uses this
estimation to try to produce a normalised speed for each
implementation. Also, these figures come from various
different sources, and reflect different peoples
benchmarks; they may not be directly comparable.
Nevertheless, the fastest PROLOGs are clearly very much
faster than the slowest. This at least partly reflects the
fact that some of these systems are interpreters only,
while some have compilers. Certainly Sigma has no compiler,
and I was unable to find one in either the Edinburgh or
Poplog systems. Given the benchmark speeds quoted, I would
suspect that none of these systems has a compiler, while I
know that all the others do.
Prices and where possible speeds have been verified with UK
suppliers.
Foreign Function Interface
All the systems described with the exception of I/F (about
interfaces to C. Specific claims are as follows:
Edinburgh
"Users can supply C bodies for Prolog predicates - this is
easy under UNIX, as the .o file can be dynamically loaded,
but we are just now doing the decomposition to let the
object file be linked into the executable under VMS (pardon
any terminology errors, VMS isn't my own field)" (source:
Correspondence with implementor)
BIM:
"BIM_Prolog has a complete interface to all procedural
languages which create a standard VAX/VMS object file.
Examples of C and Fortran are delivered with the
distribution" (source: Correspondence from BIM
representative)
"BIM_Prolog has an external language interface, although it
has no dynamic linking: it means that you can link into the
system a package (or more than one) with C functions - or
assembler, pascal, ada ... as long as the linker of VMS can
link the object of BIM_Prolog to it" (source:
correspondence with user)
LPA Sigma:
"A simple to use 'C' language interface allows new
facilities to be added quickly to the basic system"
(source: promotional literature).
Quintus:
The UNIX version of Quintus provides interfaces to C,
Pascal, and Fortran; I have no information to hand about
the VMS version. (source: User Guide)
I/F: no information
Poplog:
The Poplog environment includes LISP, POP-11, and
optionally ML in addition to Prolog, and all these can be
integrated. Additionally, "....you can link in C, Fortran,
or whatever" (source: correspondence from Prof Aaron
Sloman)
Recommendations
I would not at this stage recommend I/F Prolog, as,
although it's performance is reported to be very good, I
don't have adequate information about it; also, it's price
is extremely high. I would not recommend Sigma, as its
performance is just too poor, and this generally reflects
my experience of LPA implementations - nice systems with
dreadful performance. Also, LPA are no longer supporting
Sigma. They plan to have a new implementation out sometime
next year. Of the remaining systems:
Quintus
Quintus is (I believe) the market leader; it is solid, well
behaved and well supported, reasonably fast and not
excessively priced.
BIM
BIM_Prolog has two primary advantages: firstly it is fast;
secondly, it comes with a complete and working database
interface. Although it is more expensive than Quintus, the
benefits of a supplier supported db interface might well
more than make up for this from Savant's point of view (of
course, it would also put me out of a job).
Poplog
Is a very rich environment - far richer than is needed for
the current project. Although a nice product, it is less
suitable for our purposes than BIM, in view of its greatly
inferior speed, and lack of database interface.
Edinburgh
Is adequate for development purposes, and is very cheap.
The project would probably have to buy a faster system when
the time came to construct a marketable product.
Conclusion
Edinburgh PROLOG, plus my salary for as long as it takes to
make Edinburgh do what BIM already does, would probably add
up to a fair proportion of the cost of BIM - for a system
with markedly inferior performance.
So I (were I not me) would buy BIM (I'd want to see it first) - unless a
proprietary database interface is of primary importance; in
which case Edinburgh would do only as a cheap development
system, with Quintus being required for serious product
development.
-- Simon Brooke
--------------------------------
End of PROLOG Digest
∂12-Jul-88 0934 @SUMEX-AIM.Stanford.EDU:Acuff@Sumex-AIM.Stanford.EDU [Gregor.pa@Xerox.COM: CLOS Workshop]
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Jul 88 09:34:37 PDT
Received: from KSL-EXP-1 by SUMEX-AIM.Stanford.EDU with TCP; Tue, 12 Jul 88 09:28:14 PDT
Message-Id: <2793665457-509229@KSL-EXP-1>
Sender: Acuff@KSL-EXP-1
Date: Mon, 11 Jul 88 19:10:57 PDT
From: Richard Acuff <Acuff@Sumex-AIM.Stanford.EDU>
To: ssrg@Sumex-AIM.Stanford.EDU, aap@Sumex-AIM.Stanford.EDU
Subject: [Gregor.pa@Xerox.COM: CLOS Workshop]
Any interest?
-- Rich
------- Forwarded Message
Date: Mon, 11 Jul 88 11:02 PDT
From: Gregor.pa@Xerox.COM
Reply-To: Gregor@GRAPEVINE.parc.xerox.com
To: Common-Lisp@Sail.Stanford.edu, common-lisp-object-system@sail.stanford.edu,
CL-Object-Oriented-Programming@Sail.Stanford.edu, CommonLoops.pa@Xerox.COM
Subject: CLOS Workshop
Line-Fold: no
Workshop for CLOS Users and Implementors
October 3rd and 4th
Xerox PARC
Palo Alto, California
We have been excited by the extent to which CLOS is already being
used, and the ways in which it is being extended. The purpose of
this workshop is to provide an opportunity for the members of the
CLOS community to get together and share their experience.
To provide a good start for the interchange, we are requesting that
participants supply a short position paper (1-3 pages) describing
work related to CLOS. Some topics of interest are:
Applications
Programming Techniques
Implementation
Programming Environment Tools
Extensions of CLOS
Techniques for Converting to CLOS
Meta Object Techniques and Theory
Critiques
We will try to support demonstrations or videotapes of applications,
programming environments, implementations or other relevant systems.
If you are planning to attend, please let us know by August 15th.
This will help us with planning and allow us to arrange a discount
rate at a local hotel.
Position papers should reach us by September 9th so that we can
organize a program and arrange for duplication of the papers.
Position papers, notice to attend, and other correspondence should
be sent to:
Gregor Kiczales
3333 Coyote Hill Rd.
Palo Alto, CA 94304
or by Internet mail to:
Gregor.pa@Xerox.com
-------
------- End of Forwarded Message
∂14-Jul-88 1728 AAAI-OFFICE@SUMEX-AIM.Stanford.EDU [AAAI <AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>: Publications Committe Meeting]
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Jul 88 17:27:59 PDT
Date: Thu, 14 Jul 88 17:22:35 PDT
From: AAAI <AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>
Subject: [AAAI <AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>: Publications Committe Meeting]
To: jmc-lists@sail.Stanford.EDU
Telephone: (415) 328-3123
Postal-Address: 445 Burgess Drive, Menlo Park, CA 94025
Message-ID: <12414357520.71.AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>
You were inadvertently left off the distribution for this message.
Please let Bill know if you are able to attend.
---------------
Mail-From: AAAI-OFFICE created at 14-Jul-88 17:16:05
Date: Thu, 14 Jul 88 17:16:05 PDT
From: AAAI <AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>
Subject: Publications Committe Meeting
To: Clancey@SUMEX-AIM.Stanford.EDU
cc: reddy@fas.ri.cmu.edu, lerman@TEKNOWLEDGE-VAXC.ARPA,
nilsson@score.Stanford.EDU, englemore@SUMEX-AIM.Stanford.EDU,
aaai-OFFICE@SUMEX-AIM.Stanford.EDU, katz@mitre.arpa, bledsoe@utexas.edu
Telephone: (415) 328-3123
Postal-Address: 445 Burgess Drive, Menlo Park, CA 94025
Message-ID: <12414356337.71.AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>
The Publications Committe will meet in Saint Paul on Monday, August 22
during the lunch break of the Executive Council. The meeting will be
held in the Radisson Hotel, Room Governor II on the ballroom level.
The mail topic on the agenda will be the AI Press purposal. Lunch
will be served. Please rsvp to Bill Clancey by August 1.
Steve
-------
-------
∂15-Jul-88 0943 HEMENWAY@Score.Stanford.EDU Research Mentor Information Packet
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Jul 88 09:43:24 PDT
Date: Fri 15 Jul 88 09:41:34-PDT
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Research Mentor Information Packet
To: faculty@Score.Stanford.EDU
cc: munday@Score.Stanford.EDU
Message-ID: <12414535739.10.HEMENWAY@Score.Stanford.EDU>
It is time to update the Research Mentor Information Packet, prepared
primarily for first year students but used by all, for the 1988-89
year. I will shortly be putting copies of last year's packet into
your mailboxes, both those who were included last year and those who
were not, and ask you to return it to me with any changes. I very
strongly enourage those of you who were not in last year's packet to
participate this year. One of the most frequently heard complaints
from students is that there is no complete up-to-date listing of
research done in the department.
Please feel free to send me changes or new entries by either physical
or electronic mail. I would greatly appreciate it if new entries
could follow the format of last year's information. I will need all
new information by August 15.
Many thanks for your participation.
Sharon
-------
∂15-Jul-88 1154 @Score.Stanford.EDU:tom@polya.Stanford.EDU printer news
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Jul 88 11:54:19 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 15 Jul 88 11:52:45-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA25104; Fri, 15 Jul 88 11:52:45 PDT
Date: Fri, 15 Jul 88 11:52:45 PDT
From: Tom Dienstbier <tom@polya.Stanford.EDU>
Message-Id: <8807151852.AA25104@polya.Stanford.EDU>
To: csd@score, faculty@score
Subject: printer news
CSDCF has purchased another LPS40(SZEGO) laser printer. This printer
will be located in room 433. We plan to phase-out the existing DOVER
over a 2-3 month span. The new LPS40 should arrive by the end of this month or
early next month. Soon after delivery we expect to have it operational.
We will then have both printers operational and slowly do the DOVER phase out
or sooner if it dies beyond repair.
DSG/CSDCF people are working on creating a print server(microvaxll) that will
perform the printer spooling functions. This will solve a few problems that
now exist. It will take the spooling load off of POLYA. Will provide
printing when POLYA is down(for example, DEC maint). As it is now,
LPS40 printing can only be from host/s that provide a DECNET communication.
It will also lower the cost of support(hardware maintenance). In order
to provide maintenance for the DOVER it requires two spare DOVERS, including
the special front end ALTO's that are being stored on the 5th floor. This mass
of hardware is using up very valuable storage space. It also eliminates another
host that is on the 3MB ethernet. SAIL's connection will be the only one left
after DOVER is retired.
Most important, it will help reduce the air conditioning load in room 433.
If you have questions requarding this move to a new printer, please
send me mail. tom@polya
Tom Dienstbier
∂15-Jul-88 1503 @Score.Stanford.EDU:rw@polya.Stanford.EDU volunteer needed for orientation brunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Jul 88 15:03:52 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 15 Jul 88 15:02:06-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA02505; Fri, 15 Jul 88 15:02:11 PDT
Date: Fri, 15 Jul 88 15:02:11 PDT
From: Rich Washington <rw@polya.Stanford.EDU>
Message-Id: <8807152202.AA02505@polya.Stanford.EDU>
To: faculty@score
Subject: volunteer needed for orientation brunch
We are starting to plan out the events at the beginning of
the coming academic year. One of those events is the
brunch for new students and their student advisors.
Traditionally this has been held the Saturday or Sunday
before classes at a faculty member's house. This year that
will be September 24 or 25.
What we need is someone who is willing to host the brunch.
We'll supply help in setting up and cleaning up, and we're
also willing to take care of arranging for the food. So
all that's really involved from your standpoint is allowing
us to stand around in your yard for a few hours.
If you're interested in volunteering, please send us a
note at rw@polya.
Thanks
CSD Orientation Committee
∂15-Jul-88 1825 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #28
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Jul 88 18:24:54 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA11036; Mon, 4 Jul 88 09:21:58 PDT
Date: Mon, 4 Jul 88 09:21:58 PDT
From: Chuck Restivo <restivo@polya.Stanford.EDU>
Message-Id: <8807041621.AA11036@polya.Stanford.EDU>
To: restivo@polya.Stanford.EDU
Subject: PROLOG DIGEST V6 #28
Date: Wed, 4 May 1988 0:4:41 PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@POLYA.STANFORD.EDU>
Reply-to: PROLOG@POLYA.STANFORD.EDU>
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #27
To: PROLOG@POLYA.STANFORD.EDU
PROLOG Digest Friday, 1 Apr 1988 Volume 6 : Issue 27
Today's Topics:
Implementation - Trilogy & Destructive Assignments,
& Simple Problem & end_of_file,
& BSI Standard & A Wager
----------------------------------------------------------------------------------------------------------------------------
Date: 23 Mar 88 19:44:15 GMT
From: pacbell!att-ih!alberta!ubc-cs!voda@AMES.ARC.NASA.GOV (Paul Voda)
Subject: Compilation in Trilogy
Here is the answer formulated in a slightly more general setting:
The modes and types of Trilogy permit the native code compilation
of programs in such a way that there are no run-time tags on
most of the values, neither there are any reference counters.
The decision when to copy out and when to share the
values of input-output variables is done by a compile
time data-flow analysis. Similarly, the compiler of Trilogy checks whether
the output variables are assigned values in all branches of a predicate
(whether all input-output variables are initialized). There
is also a check to see that if-then-elses do not backtrack
(either before thens or among the branches), e.g.
if x = 1 | x = 2 then
x <> 1 & P(x)
else
......
end
The above is dissalowed by the compiler if x is output or
symbolic (logical), but is OK if x is input or input/output.
Thus we can guarantee that the negation of the formula
before a then is always properly computable.
Consequently if-then-elses and the formulas before thens
are compiled without any settings of choice points. We are
just releasing a version where non-backtracking ors (|)
(implemented by jumps instead of choice points) are permitted
in procedures (this is useful for the writing of the Trilogy
counterparts of Pascal's boolean functions).
There are two situations where the run-time tags on Trilogy values
are present:
1) the tags discriminating the union values, these should
be also present in Pascal programs.
For instance, the universal type U of all Trilogy's values has a
form of a union:
U = R(R) | S(S) | P(U,U)
The tags R(eal), S(tring), and P(air) are thus present in the
values of U variables.
If a value is not of a union type (tuple, list, array,
integer, enumerated-type etc.) then it contains no tags,
except of course the tags of any of its union constituents.
2) When a variable is of symbolic (logical) mode then Trilogy
uses the type specific tags to identify the constraints
attached to the variable (=, <, <>, etc.).
Because of the typing, modes, pred/proc modifiers and a quite extensive
data-flow analysis the compiler of Trilogy produces a procedural
code of Pascal-like quality while offering all the high-level
comfort of symbolic values with their associated constructors
and destructors as we know it from Prolog.
------------------------------
Date: 16 Mar 88 23:35:51 GMT
From: sanjay@arizona.edu (Sanjay Manchanda)
Subject: Logic of Database Updates
I have worked on doing database updates in Prolog in a "logical"
fashion. A database update is essentially an assignment on the
database. If we are going to update the database, why not first
develop a logic for reasoning about database assignments, and then
mechanize it in the true logic programming tradition? A dynamic
logic is a reasonable choice for this task, since dynamic logics
were developed to reason about programs which explicitly manipulate
their state (i.e. do assignment). I have developed a dynamic
logic for reasoning database updates that doesn't look much like the
dynamic logic's that you may have seen, but it leads to a simple
extension of Prolog.
Instead of going into the logic, I will briefly explain the extension of
Prolog. Richard introduced it rather well in a previous
message, so let me borrow some of his words.
>Roughly speaking, there are three classes of predicates:
>
> pure predicates (don't depend on things that change)
>
> state predicates (depend on things that change, but change nothing)
>
> transition (or dynamic) predicates (express a relation between states)
>
>For example, we might say
>
> p(X) :-
> <-fred(X)> q(X).
>
>p(X) is true in a world W if there is a world W1 such that
> -(fred(X), W, W1) -- roughly, retract
>and q(X) is true in W1.
>
>Note that this doesn't change W.
There are two sets of predefined dynamic predicates, +p and -p for
every pure predicate p. Actually, to avoid some thorny
implementation and semantic problems, p is restricted to be a pure
predicate that is defined entirely by ground Prolog facts. For
obvious reasons, such a predicate is called a database predicate.
New dynamic (or transition) predicates can be defined by means of
Update Rules. For example, we might say
add_flight(Fno, Src, Dest) <--
airport(Src), airport(Dest),
<+flight(Fno, Src, Dest)>.
The use of the `<--' instead `:-' signals that a dynamic predicate is
being defined. Here the semantics of add_flight(Fno, Src, Dest) is
a transition from a world W to a world W1, such that (airport(Src),
airport(Dest)) is true in W, and W1 is obtained from W by adding
the fact flight(...) to W. Thus, viewed as an operator, + is
roughly equivalent to assert.
The rule may be used in a top level query like:
:- <add_flight(20, 'LA', 'OHARE')>reachable('LA', 'JFK')
which is true in a current world W if there exists W1 accessible
through the meaning of add_flight(..), and reachable('LA','JFK') is
true in W1. Assume that reachable is the transitive closure of the
flight relation. The execution of the query is not very different
from Prolog execution. Thus the call <+flight(..)> will return a
new (world) database in which reachable(...) will be evaluated. If
this evaluation fails, backtracking will cause the inserted fact
flight(...) to be removed. Similarly, deletion on the database is
undone on backtracking.
If the query succeeds, it will return a new updated database and
display to the user, all the changes that have been made to the
current database. The user can then choose to commit these changes
and make them permanent, or reject them and leave the database
unchanged.
The language has a well-defined declarative semantics, and a syntax
that reflects this semantics. This makes it considerably better
than using assert and retract for database updates. As an example,
note that in my proposed extension, updates are statically scoped.
If p(X) is pure predicate or a state predicate, the database is
guaranteed to remain unchanged after it is executed. This can be
quite significant for compiler and database query optimization.
I did not allow updates to rule-defined predicates because I wanted
to guarantee that (not p(a)) was true after executing <-p(a)>.
However, I think that can extend the treatment if I use a weaker
semantics. I will mail copies of [1], [2] and [3] to anyone who
requests them. My apologies to Richard for forgetting to mail him a
copy of my paper.
-- sanjay
References:
[1] Sanjay Manchanda and David Scott Warren.
A Language for Database Updates.
In Jack Minker, editor, Foundations of Deductive Databases and
Logic Programming, Morgan-Kaufmann, Los Altos, CA, 1987.
[2] Sanjay Manchanda, Soumtira Sengupta, and David S. Warren.
Concurrent Updates in a Prolog Database System
Technical Report 86/28, Department of Computer Science,
SUNY at Stony Brook, Stony Brook, NY 11794,
December 1986, Revised Feb 1987.
[3] Sanjay Manchanda
A Dynamic Logic Programming Language for Relational Updates.
Phd Thesis, SUNY at Stony Brook, Stony Brook, NY 11794, December
1987.
------------------------------
Date: 17 Mar 88 03:49:59 GMT
From: munnari!vuwcomp!lindsay@uunet.uu.net (Lindsay Groves)
Subject: mine embarrassingly simple problem
I'll save Richard saying it -- this doesn't say much about the program, and
certainly doesn't explain why ancestral cuts are supposed to be necessary.
Could you describe the problem in a bit more detail and illustrate just
how the need for ansectral cuts arises? Perhaps a simplified version of the
problem could be used to illustrate the point. An example would certainly
help.
-- Lindsay Groves
------------------------------
Date: 23 Mar 88 01:16:54 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Subject: mine embarrassingly simple problem
In that case, why not just code it as
map(Function, Network) :-
generate(Function, Network),
test(Network),
!.
test(Network) :-
lemma(Network, StopCondition).
More generally, suppose that you had several cases:
test(Network) :-
lemma(Network, ~~~),
!(map(_,_)),
p(...).
...
test(Network) :-
lemma(Network, ~~~),
!(map(_,_)),
q(...).
Then you could recast this as
map(Function, Network) :-
generate(Function, Network),
test(Network, Continuation),
!,
finish(Continuation, ...).
finish(p, ...) :-
p(...).
...
finish(q, ...) :-
q(...).
test(Network, p) :-
lemma(Network, ~~~).
...
test(Network, q) :-
lemma(Network, ~~~).
The basic idea is to redesign your "test" code so that it breaks into
three pieces: before-the-cut, the ancestral cut, and after-the-cut,
and then unfold the call to it so that the cut is exposed in "map".
------------------------------
Date: 20 Mar 88 20:55:02 GMT
From: lagache@violet.Berkeley.EDU (Edouard Lagache)
Subject: My views on developing a PROLOG standard
To help get the creative juices flowing on those position papers,
I thought I would throw in my two cents worth on this proposed
standard.
While I am not really qualified to make much commentary on the
subject (So what? that has never stopped me before!), there are a
number of peripheral matters that I would like to see addressed.
The matter of greatest concern for me is the question of whose
standard will be the standard? The BSI group is a British standard;
Now I hear that the French are working on their own standard (the AFNOR
group). All this is fine and good except that in all likelihood the
resulting standards will have about as much similarity with each other
as the French and English (natural) languages do (never mind the fact
that neither standard will have have much to do with existing practice)
- This is progress!?!
Perhaps this is a wild fantasy on my part, but I would really
like to see ONE (1) standard. That standard should be agreed upon not
just by the British and the French, but by ALL the major users of
PROLOG which includes (at the very least) most of Europe, Japan, and
the U.S. It seems to me that someone should bug the ANSI standard
committee, NOT to come up with their own standard (Lord have mercy on
all those "C" and FORTRAN users once the new standards are in place),
but to take part in an international effort to come up with the before
mentioned 1 PROLOG standard.
Fantasies aside, I do have a few comments on the BSI standard. On
the specifics of the "grimoire", I can only steal a quote from the
venerable Michael Clancy: "Do the right thing". In this case, "Do the
right thing" means try to capture existing practice as much as possible
(see "lots of smoke" on exactly what existing practice means on the
FORTRAN SIG). I do believe that asking the question of how existing
code would run under the new standard is a valuable measure of the
success at capturing existing practice. Unless there is a *strong*
reason to change syntax, the new standard shouldn't depart from
existing practice. Thus, I have read Richard O'Keefe's comments on his
perceptions of the standard syntax with real concern. Until I see a
"reasonable" reply from the standards committee, I am inclined support
Richard O'Keefe's position on this matter.
At the end of last week there was some discussion of the standard
library. Here I have one suggestion, make the library big enough so
that people don't have to reinvent the wheel all the time. I took a
lot of heat for my imfamous PROLOG libraries, while the code quality
was perhaps inadequate, I believe that the concept was valuable. Even
in as rich a language as Franz LISP, I still found the need for 1600
lines of additional general purpose functions. So there is a lot of
room expansion in PROLOG.
I would like to suggest defining a separate set PROLOG libraries,
much in the same way the UNIX "C" library is (was?) defined
independantly of the language. In this area, I would strongly suggest
various levels of libraries. There should be some core set that would
be required for the standard language, then additional standards would
be defined for supplemental libraries. <*Fantasy mode on*> Ideally
the standards committee should provide source code for those
supplemental libraries in the core standard language (when possible),
so that anyone using any standard PROLOG implementation could use the
full set of libraries (if more slowly than if all the predicates were
builtin). <*Fantasy mode off*> In any case, Everybody knows that the
first thing PROLOG system implementors do is to embellish on the
standard core library, so wouldn't it be nice if the standard included
a few hundred predicates to keep those implementors busy upgrading
their product in a standard way (maybe I should have kept Fantasy mode
on?)
The last thing I would really like to see is some vast
improvement in the standard user interface tools. Even if not all
hardware can support it, I would like to see some standard way to
access windows, i/o devices (i.e. mice), and or forth. If one could
write complete applications in PROLOG that had portable "bells and
whistles", that would make PROLOG much more attractive for those trying
to make polished products for end users, since that would greatly reduce
porting problems (I know, Fantasy mode is still on!)
Still dreaming in California,
-- Edouard Lagache
------------------------------
Date: 23 Mar 88 01:09:49 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Subject: My views on developing a PROLOG standard (long but fun!)
Wrong. Roger Scowen of NPL get the thing started; since the NPL is in
England he naturally got the thing started as a BSI project. AFNOR are
not developing a rival standard; they have been collaborating with the
BSI group for a long time now, and the Formal Specification is French work.
(While many people will find it the most confusING part of the BSI material,
it is arguably the least confusED.) The whole thing has now become, I hear,
an ISO "work item", and the more recent BSI documents bear ISO reference
numbers.
> That standard should be agreed upon not
> just by the British and the French, but by ALL the major users of
> PROLOG which includes (at the very least) most of Europe, Japan, and
> the U.S.
Hear hear. And don't forget the South Pacific (home of NU Prolog and CLP)
or Israel (home of Wisdom Prolog).
> I took a
> lot of heat for my imfamous PROLOG libraries, while the code quality
> was perhaps inadequate, I believe that the concept was valuable.
Too right.
> The last thing I would really like to see is some vast
> improvement in the standard user interface tools. Even if not all
> hardware can support it, I would like to see some standard way to
> access windows, i/o devices (i.e. mice), and or forth.
I understand that agreement on the Common Lisp binding for X is at least
a year away. Plagiarism being the sincerest form of flattery, I suggest
that it might be an idea to wait for the Lisp people to do the work, and
then transliterate as much of it as possible. Or would a 'curses'
binding be of more immediate use? Either way, I don't see any need for
a standard way to access Forth; Postscript maybe, but not Forth (:-).
-----------------------------
Date: 21 Mar 88 09:26:04 GMT
From: nsc!taux01!shahaf@decwrl.dec.com (Shahaf Moshe)
Subject: mine embarrassingly simple problem
First I would like to make two comments:
* I am a NOVICE (in Prolog).
* I do not claim that in my application Ansectral Cut are a MUST. I wrote it on
a system were it was a feature and I used it. Since its not available in
Quintus Prolog, I asked for help.
About the application,
The program looks for best mapping of a Boolean function onto a set of logic
primitives such as
X * Y * Z maps to: 2inputAnd( 2inputAnd( X, Y) , Z)
or: 3inputAnd( X, Y, Z)
Since the search space is huge I used Ansectral Cut to abort
mapping once I get some "STOP CONDITIONS".
The program looks like:
map(Function,Network) :-
generate(Function,Network),
test(Network).
test(Network) :-
lemma(Network,StopCondition),
!(map). %this cut aborts the process.
I hesitate to post longer description on the net. If anyone would like to
get more elaborated data I will mail upon request.
------------------------------
Date: 19 Mar 88 03:04:08 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Subject: behavior of read/get0 at end_of_file
I thought you might be interested to know what the BSI committee say.
In document PS/236, "Draft minutes, Prolog Built-In Predicates meeting,
10 December 1987", we find
4 Design criterion
<name deleted> suggested: "Whenever possible, a predicate with
a side effect should always succeed and never instantiate
variables."
This of course rules get0/1 and read/1 out entirely. That may not be
what <name deleted> _meant_, but it _is_ what the minutes say he _said_.
As far as I can tell, the real intent is to rule out retract/1, which
is disliked because it unifies its argument with the thing you removed.
The minutes show that Paul Chung proposed naming the standard clause-
removing predicate delete/1 instead of retract/1. Good on yer, mate!
This should not be construed as endorsement of the name delete/1, but
as praise for Paul Chung's good standardisation manners.
------------------------------
Date: 22 Mar 88 15:56:23 GMT
From: mcvax!unido!ecrcvax!micha@uunet.uu.net (Micha Meier)
Subject: behavior of read/get0 at end_of_file
This is true, we have to distinguish various uses
of get0/1. The above example is indeed easier
written when get0/1 fails at the eof, because the is_endfile/1
test is not needed. However, most often one wants to do more
with the character rather than just test the eof, and only
then the differences are meaningful.
By the way, get0/1 does *not* exist in BSI, it uses get_char/1 instead,
and its argument is a character, i.e. a string of length 1.
This means that the type 'character' is inferred from
the type 'string' (and not the other way round like in C).
Does anybody out there know what advantages this can bring?
It is independent on the character <-> integer encoding,
but this only because explicit conversion predicates have
to be called all the time.
In his tutorial to the SLP '87 Richard has taken another
representation of a finite automaton which is more
appropriate:
s1 :-
get0(Char),
s1(Char).
s1(0'a) :-
s2.
s1(0'b) :-
s1.
s1(-1) :-
accept.
The difference is, that if one wants to perform some action
in some states, this must be done *before* reading the next character,
i.e. just at the beginning of s1/0. Such representation can
be more easily converted to the BSI's variant of get:
s1 :-
% do the corresponding action
( get0(Char) -> s1(Char)
;
accept
).
s1(0'a) :-
s2.
s1(0'b) :-
s1.
Note that the eof arc has to be merged into s1/0 in this way
since if we'd write it like
s1 :-
s1_action,
get0(Char),
!,
s1(Char).
s1 :-
accept.
then after an eof we would backtrack over s1_action and undo
what we've done.
I must say, none of the two seems to me satisfactory. Richard's
version is not portable due to the -1 as eof character. We can
improve this into
s1(X) :-
eof(X),
accept.
s1(0'a) :-
s2.
s1(0'b) :-
s1.
and hope that the compiler will unfold the eof/1 inside the
indexing mechanism, otherwise we have choice points even
if the code is deterministic.
The BSI version is much more arguable, though. Having to
wrap a disjunction (and a choice point) around the get0/1 call
suggests that for this application the BSI choice is not
the appropriate one. It is interesting to note, however, that
it could work even with nondeterministic automata, where the BSI's
failure was (I thought) more likely to cause problems.
For a Prolog system it is better to have get0/1 return
some *portable* eof (e.g the atom end_of_file, for get0/1
there can be no confusion with source items) instead of
some integer.
This, however, just shifts the problem up to read/1:
BSI objects that if it returns e.g. the atom end_of_file
then any occurrence of this atom in the source file
could not be distinguished from a real end of file.
In this case, a remedy would be the introduction of
a term with a local scope (e.g. valid
only in the module where read/1 and eof/1 are defined) and
using eof/1 instead of unifying the argument of read/1 with
the end_of_file term. Hence read/1 would return this term
on encountering the file end and eof/1 would check whether
its argument is this term.
--Micha
------------------------------
Date: 20 Mar 88 20:51:12 GMT
From: lagache@violet.Berkeley.EDU (Edouard Lagache)
Subject: Seeking opinions on BSI PROLOG standard proposal.
I spent a few hours carefully collecting all the
comments on the proposed BSI PROLOG standard that have been
posted to the PROLOG SIG. The result was a 160Kb file! The
reason for this exercise in tedium was my desire to write an
article on the pros and cons on this standard for the next
issue of the PROLOG Forum newsletter. However, for obvious
reasons, I am not particularly anxious to try to comb through
all them bytes of complex argumentation, and I am not
optimistic that I could do any of the participants justice.
Thus, I would like ask those persons who expressed some
substantial position on the new PROLOG standard, if they
might be interested in submitting to the PROLOG Forum
something equivalent to a short (1-3 page) position paper on
the standard.
Because we are such a new group, our editorial policies
are still in the process of coalescing, but at the moment I
would think that a very informal sort of piece of the sort
that you might post to the net would be very acceptable.
Should you have any interest and/or questions please
direct them to me, and I will do my best to answer them or if
necessary to rely them to our newsletter editor.
I am looking forward to a lot of interesting commentary!
-- Edouard Lagache
P.S. A minor detail, but anyone wishing to submit a text can simply
e-mail it to this account. If prefered, one could send an
PC or Mac compatible disk with the text in "flat ASCII" format to:
The PROLOG Forum
P.O. Box 3826
Redwood City, CA, 94064, USA.
------------------------------
Date: 21 Mar 88 16:40:44 GMT
From: eagle!icdoc!doc.ic.ac.uk!cdsm@ucbvax.Berkeley.EDU (Chris Moss)
Subject: BSI
Forwarded for Roger Scowen -- KRG0@gm.rl.ac.uk
RESPONSE TO COMMENTS FROM RICHARD O'KEEFE ON PROLOG STANDARDIZATION
GENERAL RESPONSE
Richard O'Keefe started by saying that he would respond to the
mailing from Chris Moss. In fact many comments refer
to a document (Prolog syntax, Draft 4.1) that
most news readers (and members of the ISO and BSI panels) will
not have seen.
This seems somewhat unfair on readers who will be unable to judge
whether draft, criticism, or rebuttal is justified.
First some general comments. The objective is to define an
International Standard for the programming language Prolog.
This means that standard conforming programs will run correctly
on standard conforming processors, neither more nor less.
It will not limit implementers from introducing new features and
facilities into their Prolog compilers.
Neither will it mean programmers cannot use such extensions; only
that if they do, their programs will not conform to the standard.
But a standard will permit people and companies to write applications
and libraries that will run on any conforming implementation
and thus give them a framework in which to work. In particular, such users
and their customers will not be restricted to a single implementation.
A standard will also give teachers, authors and students a common core
of useful Prolog.
Once a feature has been included in a standard, it is almost
impossible to remove. The committee remembers that Fortran has been
burdened with arithmetic if statements and computed goto statements.
In Prolog we hope to avoid such legacies if possible.
So some features of Edinburgh Prolog will not be in the standard
because although they fulfilled a need at one time, they are
not a sensible longterm solution.
Now some replies to specific criticism.
DIVERSITY OF EXISTING PROLOG SYSTEMS
Chris Moss has produced tests that give
different results on every system tested so far. Perhaps there
is rather more diversity than Richard O'Keefe realizes.
One objective has been to define a syntax where many existing
systems would not generally disagree on the meaning of
standard-conforming programs.
PROLOG CONTROL STRUCTURES AS SYNTAX
> (3) The attempt to describe Prolog control structures as *syntax*
> is fundamentally misdirected.
This is a matter of opinion. One reason for regarding Prolog control
structures as *syntax* is so that a person or program reading
a Prolog program can always recognize its overall structure.
NOTICE OF MEETINGS
Meetings are planned and advertised several months in advance,
for example, the following meetings are already planned:
BSI, London on Thursdays 2nd June, 1st Sept, 1st December 1988.
Any extra meetings to discuss the syntax will be on the previous
day (i.e. 1st June, etc); any meetings to discuss built-in predicates
will be a week later, i.e. 9th June, etc.
Everyone who wishes to attend is welcome. I admit that pressure of
work means that some papers are sent only a week before the meeting.
This is ample for British members of a British panel, but not for
Californian members.
But other papers will have been sent four or five weeks earlier.
All comments, whether they are received before or after a meeting,
are read and considered.
',' and '&' AS OPERATORS
It is not intended that it will be possible to declare ',' and '&'
as operators.
A MISTAKE IN COMMENTS
/** By L22, this is not a legal comment **/
Thank you. This will be a valid comment in standard Prolog despite
the error in this draft.
QUOTE OPERATORS USED AS OPERANDS
Richard O'Keefe realizes that the above example is intended to be
syntactically incorrect in the standard. When operators are
used as operands, there many problems of possible ambiguity.
A cure is still under discussion, but some problems are
avoided by the rule that "An operator used as an operand must be
bracketted".
AN INFIX CONS OPERATOR
We are still considering the problems posed by the multiple uses of '.',
i.e. as a decimal point, as an infix cons operator, and as a clause
terminator. At the same time we desire to make layout characters
unimportant in determining the meaning of a program.
Several possibilities have been suggested and are under consideration.
NEGATION
It is intended that Standard Prolog will not contain 'not' or '\+'.
Standard Prolog will not require systems to implement true
logical negation and it would be misleading to include an
operator or predicate that implies that they have done so.
Instead the way is left open for processors to implement a version
of 'not' as an extension and still remain standard conforming.
Standard Prolog will contain a built-in predicate
that implements 'negation by failure', i.e.
fail_if(G) :- call(G), !, fail.
fail_if(_).
A PARSER AS STANDARD
A program that resolves ambiguity implicitly is not acceptable as
defining a standard; there must be further definition.
One reason is that a program specifies too much. Some features need to
remain 'implementation dependent' because we must not specify
them, for example: the accuracy and largest values of floating point
numbers, or the integer value corresponding to a character.
Another reason is that it is harder to understand and find errors.
DISCLAIMER AND CONCLUSION
Never rely on working papers and draft standards. They are subject to
changes and review. All documents and working papers, however
confidently expressed, are also subject to review. There will be no
standard until the member bodies of ISO have approved it.
The next working drafts will incorporate changes arising from further
consideration and the comments received (including those from
Richard O'Keefe).
Many countries, but not at present USA, have national Prolog panels
coordinating their views on the emerging standard. I encourage all
Prolog implementers and users to participate in this effort in order that
the eventual standard is one that preserves the best of the past
and also provides development paths for the future.
-- Roger Scowen
-------------------------------
Date: 23 Mar 88 05:11:45 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Subject: BSI syntax
Message-Id: <797@cresswell.quintus.UUCP>
References: <234@gould.doc.ic.ac.uk>
Sender: prolog-request@score.stanford.edu
To: prolog@score.stanford.edu
My postings were in fact a response to Chris Moss's mailing. They were
not confined to the content of that mailing, true. It seemed to me that
Chris Moss's mailing implied that the BSI syntax was in a satisfactory
state, and that it wasn't as difference from the de facto standard as
people feared. I set out to show that neither of those statements is
true, and I believe that I succeeded.
Many comments did refer to a document that most news readers won't have
seen. But then, most news readers won't have seen ***ANY*** of the BSI
documents. Am I then to say nothing? As for fairness to readers,
(a) I was quoting from the very latest document I had.
Surely it would be more unfair to quote from something I believed
to have been superseded?
(b) The "February 88" and "Feb 88" documents arrived in my mailbox here
in the same week. I had no way of telling who had or had not
received the document I was quoting. All I knew was that this was
the latest document available, sent to me by the author.
(c) In order to permit readers to judge for themselves whether my
criticisms were justified, I quoted extensively from the document.
I did not ask anyone to take it on faith that this or that was the
case: where the grimoire appeared to say something particularly
silly I exhibited the rules responsible. This is unfair?
> First some general comments. The objective is to define an
> International Standard for the programming language Prolog.
> This means that standard conforming programs will run correctly
> on standard conforming processors, neither more nor less.
> It will not limit implementers from introducing new features and
> facilities into their Prolog compilers.
>
> Neither will it mean programmers cannot use such extensions; only
> that if they do, their programs will not conform to the standard.
>
This is a little misleading. The general rule in other languages is
that implementors can add extensions, provided that such extensions
are either illegal or undefined in the standard. Thus a Pascal compiler
can provide alphabetic labels as an extension. But an implementor
should not provide an extension which alters the meaning of a program
which the standard would have ruled legal.
Let's apply this to the case of :- read(_). directives in a file which
is being consulted or compiled. Specifically, let's consider a file
which looks like
:- read(_).
p(a).
and has nothing else in it. Does this define p, or does it not? The
BSI grammar, in all versions, provides the syntax of entire files:
according to the grimoire this MUST mean exactly one directive followed
by exactly one clause. Since this is a defined and legal file, it would
be most improper for an implementor to give it any other meaning.
Therefore, reading out of a file being compiled or consulted is NOT
a permitted extension. (This wouldn't bother Quintus, but it is legal
in some other Prologs.)
Let's apply this to another case: functor/3. It has always been the
case in DEC-10 Prolog that functor(1, 1, 0). In at least one draft of
the BSI built-in predicates document, this has been required to raise
an error. (BSI Prolog includes an error handling facility; needless
to say it doesn't look like IF/Prolog's or M-Prolog's or ...) So a
BSI conforming program is entitled to rely on this error being raised,
and an implementor may NOT provide DEC-10 compatibility.
The ANSI C committee have found it necessary to explicitly indicate
which identifiers may be used by implementors. (The list includes
all identifiers starting with "_" or "str" and there are others I
can't remember right at the moment.) Why is this? Because the
programmer needs a guarantee that the identifiers he has chosen for
his code won't be in conflict with an implementation. For example,
(not)/1 is not defined in the BSI stuff, so Scowen says that an
implementation is free to define it. But if the implementation is
free to do so, then the programmer ISN'T. Since setof/3 is not in
the BSI Prolog language, a program which defines
setof(List, Set) :-
setof(List, [], Set).
setof([], Set, Set).
setof([Head|Tail], Set0, Set) :-
( member(Head, Set0) ->
setof(Tail, Set0, Set)
; /* not member(Head, Set0) */
setof(Tail, [Head|Set0], Set)
).
is a standard-conforming program. But a Prolog system which is exactly
BSI except for providing setof/3 as an extension is a conforming processor.
Will such a conforming program run correctly on such a conforming
processor? You must be joking. So, taken in their ordinary sense,
the claim that "standard conforming programs will run correctly on
standard conforming processors", while true of some standards, is NOT
true of the BSI work, unless "standard conforming processors" is
construed very strictly as meaning "providing NO additional built-in
predicates".
You will recall that Fortran 77 provides the EXTERNAL and INTRINSIC
statements precisely to cope with this problem, and that ANSI C
provides the reserved-to-implementors list and #undef precisely to
cope with this problem. BSI Prolog does have some reserved words,
but is ludicrously far from providing a solution to this problem.
> So some features of Edinburgh Prolog will not be in the standard
> because although they fulfilled a need at one time, they are
> not a sensible longterm solution.
Let's be realistic. There are languages on the horizon which are much
better approximations to logic programming than Prolog. (NU Prolog has
been around for a while.) There are lots of software engineering needs
which old Prolog completely failed to address, such as modules. (Last
I heard, the consensus of the BSI Modules subcommittee was that they
would probably never agree.) I think we ought to regard Prolog as a
stopgap; and that the goal of the standard should be to protect EXISTING
investments in Prolog. Frankly, advocates of BSI Prolog, with its
use of user-supplied atoms as stream names, are in no position to talk
about sensible solutions.
************************************************************************
** It would be most interesting to have an explicit list of the features
** of Edinburgh Prolog which fulfilled a need at one time and are now
** disliked by the committee, and a description of their replacements.
************************************************************************
> > (4) The basic structure of the BSI approach to syntax has been
> > to cut the Gordian Goose. That is, instead of regarding the
> > (actually rather low) diversity of Prolog syntax as an
> > opportunity to be solved by making the language more powerful
> > (e.g. having a table-driven tokeniser), it has been treated as
> > a problem to be solved by inventing a new, more restricted,
> > language.
>
> Well, yes and no. Chris Moss has produced tests that give
> different results on every system tested so far. Perhaps there
> is rather more diversity than Richard O'Keefe realizes.
> One objective has been to define a syntax where many existing
> systems would not generally disagree on the meaning of
> standard-conforming programs.
The amount of diversity one perceives depends on which "Prolog" systems
one decides to include in one's sample. My sample includes only systems
whose implementors _tried_ to be Edinburgh (or at least Clocksin &
Mellish) compatible. For example, AAIS Prolog is openly and frankly
not an Edinburgh-compatible system. We may (and should) look to it for
ideas, but we should not include it in a sample of "Edinburgh compatible"
Prologs. BIM Prolog has its own unique syntax; while we should perhaps
include the '-c' syntax of BIM Prolog in the sample, we should not
include BIM Prolog's native syntax. If we go by numbers, then Turbo
Prolog should determine the syntax of standard Prolog. If not by numbers,
by what? Simple justice suggests that the Prologs to look at are the
Prologs whose authors TRIED to be compatible with one another. Prudence
suggests the same sample.
But even if the diversity among the Prologs whose authors didn't suffer
from NIH-itis is much greater than I believe, that doesn't answer my
point. What I said was that the diversity should be regarded "as an
opportunity to be solved by making the language more powerful (e.g.
having a table-driven tokeniser)". [As an aside, this is no more than
Lisp and PopLog already have.] It turns out that it is quite easy to
write a tokeniser which can handle all of
ALS Prolog
Arity Prolog
BIM Prolog native syntax
C Prolog
DEC-10 Prolog
PopLog (nested comments)
Quintus Prolog
Stony Brook Prolog
and can almost handle ADA [ADA is no longer a trademark], simply by fiddling
with a table. AAIS took exactly this approach (though their tokeniser is
not as flexible as mine). I found it necessary to support several kinds
of quotes in my tokeniser:
ATMQT - the quoted thing is an atom (')
STRQT - the quoted thing is a string ($)
LISQT - the quoted thing is a list (")
CHRQT - the quoted thing is a character (`)
Suppose the standard were to adopt this approach, then they could rule,
if they wished, that the standard assignment was "->STRQT, with nothing
being assigned LISQT. That needn't prevent me reading my existing code:
I'd be able to change the table while reading my old files.
[The best approach seems to be to associate a read table with a stream;
naturally this is the approach PopLog takes.]
What I have in mind here is that a file would start with a directive
such as
:- use_syntax(dec10).
or :- use_syntax(standard).
or :- use_syntax(als).
Especially if the tokeniser were made available to user code (as it is
in the DEC-10 Prolog library, or built-in in NU Prolog), the result would
be a much more powerful language at very little cost to the implementor.
And conversion from old dialects to the BSI dialect would be enormously
simplified.
Do we need to come up with a "best possible" tokeniser for the standard?
Of course not.
Again, what are we to do about syntactic variations, such as the
treatment of operators? My answer, in 1984, was that the standard
should not specify read/1 and write/1, but should specify
standard_read/1
standard_write/1
and should allow users to redefine read/1 and write/1, but require
that the initial definitions be the standard one. consult and compile
should use read/1, not standard_read/1, so that someone who wanted to
read M-Prolog files into standard Prolog could do so by suitably
defining read/1.
Now, if you are a self-appointed standards committee member determined
to impose your vision of what is a "sensible longterm solution" on
every Prolog user whether they like it or not, this sort of approach
won't seem all that attractive. But if, like me, you think that the
people who matter in all this are the people who have paid money to
USE Prolog, and if, like me, you think that the fact that M-Prolog
is appalling is no reason to make life any harder for people with a
lot of data in M-Prolog format than we have to, you'll think that
letting people do
read(Term) :- magyar_read(Term).
is obviously the way to go. (It doesn't much matter how you install
your own code in the hook, the important thing is that there should be
a read-hook where you can install your own reader to be used by compile
and consult.)
> PROLOG CONTROL STRUCTURES AS SYNTAX
> > (3) The attempt to describe Prolog control structures as *syntax*
> > is fundamentally misdirected.
> This is a matter of opinion. One reason for regarding Prolog control
> structures as *syntax* is so that a person or program reading
> a Prolog program can always recognize its overall structure.
It is not a matter of opinion. Either I am right about this, or I am
wrong. There is a very important reason for my belief: Prolog is
simply not the sort of language for which this kind of thing can WORK.
Consider the difference between
foo(X, P, Q, L) :- bag(X, (P & Q), L).
↑↑↑↑↑↑↑
and
de_morgan((P & Q), (R | S)) :- de_morgan(P, R), de_morgan(Q, S).
↑↑↑↑↑↑↑
The first is code, and the treatment of it in the grimoire is appropriate.
(That is, it will be mapped to whatever "(and ?P ?Q)" would have been
mapped to in the BSI Lisp-like syntax.)
But the second is data, and the treatment of it in the grimoire is
NOT appropriate. It will be mapped to whatever "(and ?P ?Q)" would
have been mapped to in the BSI Lisp-like syntax, but it SHOULD be
mapped to whatever "[& ?P ?Q]" would be mapped to.
If we consider a slightly different example:
baz(X, P, L) :- bag(X, P, L).
↑
and
de_morgan(not(P), R) :- de_morgan(P, R).
↑
we find the opposite problem: the second is data and will be mapped to
whatever "?P" will be mapped to in the BSI Lisp-like syntax, but the
first is code, and should be mapped to whatever "(and ?P)" would be
mapped to, BUT IT WON'T BE.
The trouble is that the grimoire tries to guess whether something is
code or data by looking at its form, but that's the wrong place to
look: the place to look is the predicate being called. And the
trouble is that we can't build that information into the grammar,
because the programmer can define new predicates with code-like arguments.
Let me stress this:
the whole basis of the build-it-all-into-the-syntax approach
is the assumption that code is code and data are data and
never the twain shall meet.
This is true of Pascal. It is true of Fortran. It is almost true of C.
But it is utterly false of Lisp and Prolog. A grammar of this type does
not make SENSE for Prolog any more than it makes sense for Lisp.
I hereby wager US$100, payable once to Chris Moss, that if the next draft
of the grimoire attempts to maintain this rigid distinction between code
and data, I will be able to find inconsistencies like the ones above in
it. I don't think it's Chris Moss's fault: if anyone can find a way of
working around this basic mistake (not HIS mistake, by the way, this is
the kind of grammar the BSI committee have always wanted), I'm sure that
Chris Moss could. I make my wager *despite* my belief in Chris Moss's
competence, because I believe that it is _impossible_ for this approach
to work. (If I do not receive said draft by the end of this year, the
wager will expire.)
> ',' and '&' AS OPERATORS
> > Oddly enough, if one takes the grimoire literally, the user CAN
> > declare ',' and '&' as operators, and can use them in that form.
> > However, ',' and '&' cannot possibly have the same precedence as
> > "," or "&" in BSI Prolog, and it seems clear that (A ',' B) and
> > (A '&' B) must be different terms.
>
> It is not intended that it will be possible to declare ',' and '&'
> as operators.
>
There is nothing in the grimoire to say so, and it is a very odd restriction.
Intentions are beside the point: all that matters is what the documents
actually say. It *is* the intention that it should be possible to write
','(A,B) as a term, and it remains the case that ','(A,B) and '&'(A,B)
must be different terms, and if we take the grimoire literally, neither of
them can be the same as (A,B) or (A&B).
[Yes, I know about (P|Q) and (P;Q) in Dec-10 Prolog. I have always thought
and said that this was a mistake, and I think it is one of the very few
areas where a difference between the standard and existing practice might
be justifiable.
]
> QUOTE OPERATORS USED AS OPERANDS
> > compare(R, X, Y) :-
> > ( X @> Y -> R = >
> > ; X @< Y -> R = <
> > ; R = =
> > ).
>
> Richard O'Keefe realizes that the above example is intended to be
> syntactically incorrect in the standard. When operators are
> used as operands, there many problems of possible ambiguity.
> A cure is still under discussion, but some problems are
> avoided by the rule that "An operator used as an operand must be
> bracketted".
>
Well, it would be more accurate to say that I COMPLAIN that it is
intended to be syntactically correct in the standard.
There isn't any problem of possible ambiguity here whatsoever.
) :- ( :- must be infix
X @> Y @> must be infix
Y -> R -> must be infix
R = > = must be infix or suffix, has no suffix reading
= > ; > must be atom or prefix, has no prefix reading
> ; X ; must be infix
and so on
Now if = and > _both_ had a suffix reading, (R = >) would be ambiguous.
Since neither of them has, there is no ambiguity here at all.
The elimination of ambiguity is not a very good argument for breaking
existing UNAMBIGUOUS code!
> NEGATION
> > not Goal :- % "not" is not a built-in operator
> > ( ground(Goal) -> \+ Goal % neither is "\+".
> > ; signal_error(instantiation_fault(Goal,0))
> > ).
> It is intended that Standard Prolog will not contain 'not' or '\+'.
> Standard Prolog will not require systems to implement true
> logical negation and it would be misleading to include an
> operator or predicate that implies that they have done so.
> Instead the way is left open for processors to implement a version
> of 'not' as an extension and still remain standard conforming.
> Standard Prolog will contain a built-in predicate
> that implements 'negation by failure', i.e.
> fail_if(G) :- call(G), !, fail.
> fail_if(_).
My main point here was a semantic one. Most other control structures
are defined in the grammar. It seems odd that
( G -> fail ; true ) should be in the grammar, but that
fail_if(G) which is identical in effect, should not.
Because one of these forms is in the grammar and the other isn't, they
have different properties. For example,
( 1 -> fail ; true ) is syntactically illegal, but
fail_if(1) is syntactically legal.
There are other differences as well.
If BSI Prolog contains fail_if/1, then it WILL contain '\+', but with
a different name. Why not use an existing name for an existing
operation? Looks to me like nonhicinventusitis. \+ is a crossed-out
|-, meaning, obviously enough, "not provable".
> A program that resolves ambiguity implicitly is not acceptable as
> defining a standard; there must be further definition.
> One reason is that a program specifies too much. Some features need to
> remain 'implementation dependent' because we must not specify
> them, for example: the accuracy and largest values of floating point
> numbers, or the integer value corresponding to a character.
>
> Another reason is that it is harder to understand and find errors.
It is harder to understand and find errors in a program you can run
than in a never-used-anywhere-else formalism? Judging by the results,
this is the opposite of the truth.
What is the difference between the public-domain DEC-10 Prolog parser
and the BSI grimoire? Both are programs, in a formalism based on logic.
Neither is more explicit or less explicit than the other, and both are
of similar size. So what is the difference? The difference is that
the public-domain DEC-10 Prolog parser CAN be run, HAS been run, and
has had most of the mistakes knocked out of it by actual experience.
The BSI grimoire is in a new formalism, the definition of which is
provided in ***NO*** BSI document (so that I had to keep guessing what
things meant), and each of the three drafts I have seen was riddled
with errors from end to end. I haven't told you about all the problems
I found; there are nearly as many problems as rules!
The BSI Prolog group HAVE specified the integer value corresponding to
a character: they require the ISO 8859 character set. GREAT!
The DEC-10 public-domain ***parser*** does NOT specify the integer
value corresponding to a character (that's the tokeniser's job).
{The old tokeniser did have ASCII codes built in, but the current
version of the tokeniser uses 0'x syntax for the appropriate
constants to avoid that problem.}
If the BSI committee are so concerned to avoid character code problems,
how come they haven't got anything like 0'x or `x` (in a standard which
doesn't have to cope with existing code that uses ` as an atom, `x` is
a good notation for character code constants)?
The public-domain tokeniser doesn't specify anything more about floating
point numbers than what they look like, it relies on being provided with
a number_chars/2 predicate (which we want ANYWAY) do to the actual
conversion.
Note that the BSI grimoire says NOTHING about what happens if you write
a constant which exceeds the capacity of your implementation. Is the
program
p(1.2e3456).
a BSI-conforming program or not? Well, syntactically it is, but the
lexical rules say nothing about what it MEANS. For all that the
grimoire or any other BSI document I can recall says to the contrary,
a Prolog implementation which reads this as
p(0.0).
is conforming. This kind of thing is a real portability problem; it
exists with respect to integers too. Is 1000000000000000000 a legal
Prolog term? According to the grimoire, yes. What does it mean?
The grimoire doesn't say.
> DISCLAIMER AND CONCLUSION
> Never rely on working papers and draft standards. They are subject to
> changes and review. All documents and working papers, however
> confidently expressed, are also subject to review. There will be no
> standard until the member bodies of ISO have approved it.
But what ELSE is there to comment on?
> Many countries, but not at present USA, have national Prolog panels
> coordinating their views on the emerging standard. I encourage all
> Prolog implementers and users to participate in this effort in order that
> the eventual standard is one that preserves the best of the past
> and also provides development paths for the future.
>
> Roger Scowen, 11 March 1988
Sorry, but it's too late. Prolog implementors and users should have been
invited to contribute before the committee went on a four-year binge of
inventing their own language. I explicitly suggested some years ago that
the people at WISDOM should be invited to participate, and was told that
that was out of the question. I have put a lot of effort into writing
responses to the BSI stuff, and for all the feedback I've had I might as
well have been shouting into a vacuum. The BSI committee having been
resolute in their contempt for existing Prolog users (I have repeatedly
urged that they should explicitly adopt a principle of not breaking
existing code without strong necessity, as the ANSI C committee did, and
the last I heard was that they had explicitly rejected any such idea),
I cannot regard "preserves the best of the past" as anything but a sick
joke.
Look, if you want to preserve the best of the past, why have you
renamed findall/3 to bag/3? Why have you adopted ESI Prolog-2's
streams rather than Arity/Prolog's streams, despite having been
told about the problems? Could it be something to do with the
fact that the author of that part of the standard worked for ESI,
not for Arity? Why have you dropped nl/0 from the standard? Why
is there no notation for character constants such as PopLog provides?
Why is the error handling facility all new, rather than resembling
either IF/Prolog or M-Prolog?
I have tried, I really have tried, to arouse interest in the BSI work
here in the US. Do you know what has got in the way? As soon as I
show people any of the BSI documents (take the 'standardisation issues'
documents as an example) they say "what a pack of turkeys" and assure
me that there is nothing to worry about. I remain desperately worried
that there will be a BSI/ISO Prolog standard, and that it will be as
bad as the current drafts, and that it will do a great deal of damage.
What *really* worries me is that the people on the BSI committee don't
seem to realise how bad it is.
------------------------------
End of PROLOG Digest
********************
∂15-Jul-88 1831 ullman@polya.Stanford.EDU last two chapters available.
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Jul 88 18:31:19 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA17318; Mon, 11 Jul 88 17:57:36 PDT
Date: Mon, 11 Jul 88 17:57:36 PDT
From: Jeffrey D. Ullman <ullman@polya.Stanford.EDU>
Message-Id: <8807120057.AA17318@polya.Stanford.EDU>
To: nail@polya.Stanford.EDU
Subject: last two chapters available.
Ch. 16, giving an overview of NAIL!, LDL, and POSTGRES, and
Ch. 17 on universal relations, are available now (16) or very soon (17).
You can request a copy of either from Rosemary Napier (rfn@sail.stanford.edu).
I know that no one is interested in universal relations, so please
only ask for that if you want it; we made very few copies.
---jdu
PS: There are no 14 and 15 yet. 13.5-13.8 will become 15 and 13.9-13.12
will become 14.
∂15-Jul-88 1835 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #29
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Jul 88 18:34:56 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA26576; Thu, 7 Jul 88 12:06:03 PDT
Date: Thu, 7 Jul 88 12:06:03 PDT
From: Chuck Restivo <restivo@polya.Stanford.EDU>
Message-Id: <8807071906.AA26576@polya.Stanford.EDU>
To: restivo@polya.Stanford.EDU
Subject: PROLOG DIGEST V6 #29
Date: Fri 6 May 1988 0:53-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@POLYA.STANFORD.EDU>
Reply-to: PROLOG@POLYA.STANFORD.EDU>
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #29
To: PROLOG@POLYA.STANFORD.EDU
PROLOG Digest Friday, 6 May 1988 Volume 6 : Issue 29
Today's Topics:
Query - Interface,
Implementation - Strings & end_of_file
----------------------------------------------------------------------------------------------------------------------------
Date: 24 Mar 88 16:29:18 GMT
From: mcvax!ukc!dcl-cs!simon@uunet.uu.net (Simon Brooke)
Subject: Interface
Here is another embarrasingly simple problem. I'm fairly clear that there
is a simple solution... but I don't know what it is.
I am writing code to interface prolog (as it happens, Quintus) to an
external database running on a remote machine. When making a query on the
remote database, it is essential to form the best joins, because joining
the database is computationally expensive.
The geography of the database can be seen as a messy graph. Each table can
be joined to at least one other, and this possibility, together with the
fields that make it possible, is represented in prolog by the symmetrical
relation:
canJoin( [ Table1, Key1], [ Table2, Key2]).
Furthermore, we can be sure that there is at least one possible path from
any table to any other. However, joins may have to connect an arbitrary
number of tables. The rules for this are:
* A continuous join path must be found which visits every table
in the list;
* The path must not cycle;
* The path may branch.
In other words, the smallest possible tree must be formed such that it
visits all the nodes on the target list.
What I want is a predicate of the form:
findBestJoins( +TableSet, -JoinSet).
where TableSet is a set of tables to be joined, and JoinSet is a list of
join specifications (ideally in the form [ [ Table1, Key1], [ Table2, Key2]])
which describe the tree.
After looking at this ugly monster for a while, I have come up with an
English description of a procedural algorithm to tackle it, and this I
intend to code over the next few days. But that misses the point. Prolog
is supposed to be a declarative language, and this problem can easily be
described in declarative terms [look, I've done it up there :-)]. But I
can't for the life of me work out how to write it, declaratively, in
prolog. Can you?
Thank you.
-- Simon Brooke
------------------------------
Date: 26 Mar 88 06:58:22 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Subject: Another embarassingly simple problem
Isn't the matrix chain problem a special case of this?
------------------------------
Date: 26 Mar 88 06:55:17 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Subject: Strings
In article <488@dcl-csvax.comp.lancs.ac.uk>, simon@comp.lancs.ac.uk (Simon Brooke) writes:
> In article <776@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
> >Xerox Lisp uses lists for bignums to this very day.
>
> Yes, true. But please don't assume this means it is efficient.
Well, no, I didn't assume that. I was replying to a message which claimed
that "Lisp" didn't use lists for bignums any more.
> For
> example, I recently benchmarked a Xerox 1186 running Interlisp (Koto)
> against the new Acorn Archimedes running Arthur Norman's Cambridge Lisp.
> Generally the Arch was a bit faster, reflecting the simpler lisp and
> faster processor. But running (fact 1000) it was 321 (three hundred and
> twenty one) times faster - and this must reflect grotesque inefficiency in
> Xerox' bignum code.
If it was "recently", didn't you have the Lyric release?
I am shocked to hear that the Archimedes was only "a bit faster".
As you can easily find out if you have Xerox Quintus Prolog, it is a _lot_
faster at list processing than Xerox Lisp is. I would have expected
Cambridge Lisp on a RISC to be about as fast as XQP. What's wrong?
The (fact 1000) test may reflect only the simple fact that the
Archimedes has a 32-bit ALU, whereas the Xerox 1186 has a basically
16-bit ALU. It is easy to pull apart an Interlisp bignum and see what
is inside. It is a list of FOURTEEN-bit 2-s complement integers. It
works out at about 0.4 data bits per stored bit. The vector approach
should get about 1 data bit per stored bit.
Another possible consideration is storage turnover. (fact 1000) requires
over 8500 bits to represent [about 266 32-bit words, but about 610 list
cells]. The Xerox D-machines are not noted for their paging performance.
Did you make sure that all the relevant code was paged in before
measuring the performance of (fact 1000)?
------------------------------
Date: 26 Mar 88 06:12:05 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Subject: Strings
There are two separate and distinct ways of doing this using the
Quintus library, and both are documented in the Library manual.
In Section 8.3, you will find
put_chars(+Chars)
and
put_line(+Chars)
described.
These are exactly the writestring you want, except that they have
truthful names. (put_chars/1 does 'put' to a 'chars', that is, to a
list of 'char's. put_line does 'put' to a list of character codes
considered as a line; it's the equivalent of puts(3S) in the C library.)
There is also a library package called library(print_chars) which
makes the 'print'ing of chars values entirely automatic. It is
described in section 9-2-2 of the library manual. The point of this
is that once you have done
| ?- ensure_loaded(library(print_chars)).
then top-level output, debugger output, and print/1 will have this sort
of effect:
| ?- X = ["this","is","a","list","of","chars","values"].
X = ["this","is","a","list","of","chars","values"]
| ?- append("stuff", Tail, Chars).
Tail = _537,
Chars = "stuff|Tail"
{this is an excerpt from an actual transcript}. If you look in the
DEC-10 Prolog library you will find the ancestor of print_chars under
the name PORSTR.PL.
> What does that tell us about the use of strings? It suggests to
> me that people actually always use atoms for this purpose, and somewhere
> in their code is an implicit definition:
> writestring(String) :- name(Atom,String),write(Atom).
What it actually tells us is that Chris Moss didn't look very hard in
the manual. Even if the Quintus library didn't provide two ways of
doing this, what people have done in other dialects is to define
puts([]).
puts([C|Cs]) :- put(C), puts(Cs).
In fact, if I remember correctly, MU-Prolog extended put/1 to do this.
Why drag atoms into it? In fact, the code that Chris Moss shows us will
not work: writestring("00") would print a single "0". {Yes, this is not
a nice thing for name/2 to do, which is why Quintus Prolog offers
atom_chars/2 _as well_.}
> 2. I don't like having ASCII values in my programs.
As Chris Moss explained later in his posting, this is not an argument AGAINST
having a notation for lists of character codes. It is an argument FOR having
a notation for character constants.
> With a certain amount
> of discipline and inefficiency one can get round that, by saying, for
> instance:
> lowercase(X) :- "a"=[A], "z"=[Z], X>=A, X=<Z.
Why do that when you can write
lowercase(X) :- "a" =< X, X =< "z".
Better yet, why not do
lower_case(X) :- is_lower(X).
where is_lower/1 is one of the character classification predicates stolen
from C that I suggested in my 1984 "evaluable predicates" document (BSI
number PS/6). (Quintus Prolog provides this, and NU Prolog provides it
under the name isLower/1.) Best of all, is_lower/1 will solve for X...
In fact, while Chris Moss may not _like_ having ASCII values in his
programs, that's what he just did, and having a character type won't
make them go away. His code for lowercase is quite wrong for EBCDIC.
It's also wrong for ISO 8859, where there are another 64 lower case
letters. The Quintus Prolog library contains a package ctypes.pl which
comes in an EBCDIC version as well as an ASCII version, and
is_lower(X)
is the right thing to do in either context.
This is part of what I meant in an earlier posting by asking what was the
right set of operations for a character type. (How do you test whether a
character code stands for a Hebrew letter in the appropriate variant of
EBCDIC? No fair looking in the 3270 manual, now.)
> OK, there is the 0'a notation (another way of writing 97 if you're using
> ASCII). Now that DOESN'T work in MuProlog, or Poplog or ...
It _DOES_ work in NU Prolog, the successor to MU Prolog. (See section
3.2.2 paragraph (c) of the NU Prolog manual, version 1.1.) And PopLog
has `a`, has it not? It should be the work of a few minutes to convert
0'a to `a` or conversely by writing a VED or EMACS macro.
> On efficiency I mostly agree with Richard. I too like strings to be lists,
> and can't see the real benefits of a string type, though you don't tend to
> miss what you never had!
Try SNOBOL, PL/I, BASIC, Burroughs Extended Algol, AWK, Common Lisp, &c &c.
What a pain what a pain.
> As far as notation is concerned I have no better suggestion
> than 0'a though I don't much like it.
The reason that Edinburgh Prolog uses 0'x is that by the time we thought
of it, there were programs using all the other ASCII printing characters,
and the DEC-10 tokeniser already accepted 0'<digits> but didn't do anything
terribly sensible with it. The only virtue I've ever claimed for it is
that it didn't break anything. The Pop-11 `x` notation is obviously
superior as a notation. (0'x also suggests, as it is meant to, that it
is an integer. `x` doesn't suggest that, so would be more appropriate to
a separate "character" type.).
> I wouldn't object to the C solution, which allows them to be used
> in arithmetic contexts. e.g. Num is Ch-0'0 or Letter =<0'z.
But the C solution is that characters *ARE* integers.
The constant expression 'a' in C has type "int", not "char".
> Most of my suggestions at main committee meetings have been ignored!
I'm very sorry to hear that, but the quality of the BSI built-in-predicates
work seemed to me to be far too low to be compatible with the assumption that
you had much of a hand in it. This is not to say that I would expect to
_like_ your suggestions if I knew what they were, but I certainly would
expect them to be coherent and sensible.
------------------------------
Date: 27 Mar 88 00:22:18 GMT
From: defun.utah.edu!shebs@cs.utah.edu (Stanley T. Shebs)
Subject: Strings
A minor point: I don't think I claimed that "`Lisp' didn't use lists for
bignums any more"; if I did, it was a boner. For almost any possible design
choice, you can find one or more systems in the past that made that choice.
It is true that lists for bignums are unusual nowadays, but nobody (so far as
I know) has made a scientific study as to whether lists are better/worse than
vectors for representing bignums. Anybody need a masters thesis?
>Did you make sure that all the relevant code was paged in before
>measuring the performance of (fact 1000)?
Ah yes, one of the nasty little details that a truly meaningful study
would have to take into account. Still, I would expect all the relevant
code to get paged in after the first few bignums...
-- stan shebs
Date: 25 Mar 88 12:17:31 GMT
From: mcvax!enea!zyx!grzm@uunet.uu.net (Gunnar Blomberg)
Subject: behavior of read/get0 at end_of_file
Hmm... isn't this a lot of fuss about very little?
It seems to me that whatever semantics is chosen, it is simple to get
the other:
BSIread(X) :-
DEC10read(X),
X \== end_of_file.
DEC10read(X) :-
BSIread(Y),
!,
X = Y.
DEC10read(end_of_file).
Given that most Prologs seem to use the DEC-10 Prolog approach, and
that it is probably marginally more efficient to write BSIread in
terms of DEC10read than the other way around, the DEC-10 approach seems
the obvious choice. Not that I think the other choice is all that
much worse... Isn't it more interesting to discuss things where it is
harder to get it the way one wants (like the question raised by
Richard O'Keefe about whether a string data-type is necessary, or even
useful. Now *that* is interesting!)
----------
At this point I had a discussion with a colleague of mine, and it
turns out that it isn't this simple. In fact, I now believe that it
is impossible to get the BSIread functionality from a system that only
provides the DEC-10 one. The predicate BSIread above will fail if the
file read contains 'end_of_file', of course. This (for me) tips the
balance over in favor of the BSI approach. It is after all easy to
write DEC10read in terms of BSIread.
Naturally there should be a provision for compatibility with "old"
programs. I would be quite happy to name BSIread read_term, for
instance, and provide a user-level predicate read, that could be
redefined to give the required semantics.
-----------
As far as get0 goes, the question is much easier, since there *is* an
obvious out-of-band value, namely -1.
-- Gunnar Blomberg
------------------------------
Date: 25 Mar 88 12:14:47 GMT
From: mcvax!enea!zyx!grzm@uunet.uu.net (Gunnar Blomberg)
Subject: behavior of read/get0 at end_of_file
In article <801@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>[...] So the alternatives I can see at the moment
>are
> o construct a new string every time.
> o precompute 2↑16 strings.
> o cache 2↑8 strings, and construct a new string every
> time for Kanji and other non-Latin alphabets.
> o not support Kanji or other non-Latin alphabets at all.
How about:
o support an immediate representation for characters.
if you've got room for them in your pointers. Or
o cache them as they occur.
if you haven't.
I can't see that the fact that characters look like one-element strings
to the Prolog programmer in any way would stop an implementor from
implementing them using the same tricks as if characters were a
separate data-type. Yes, it makes the internal string-handling
somewhat more convoluted, but not unduly so, I would say.
-- Gunnar Blomberg
------------------------------
Date: 25 Mar 88 12:50:44 GMT
From: mcvax!enea!zyx!grzm@uunet.uu.net (Gunnar Blomberg)
Subject: behavior of read/get0 at end_of_file
Well, considering the fact that nested comments can comment out
*any* part of the file, not just the last part, and that the cases
where nested comments do not work must be so exceedingly rare as to be
practically non-existent, I would definitely prefer nested comments.
Honestly, how often do you have unmatched beginning-of-nested-comment
of end-of-nested-comment buried inside your code?
Well, just because nested comments are much more useful than
plain ones does not mean that BSI should adopt them. There is the
question of supporting "old" code. It would be interesting to know
how many programs would break if Prolog comments were changed to be
nesting. Do you know of any?
[I have actually seen the following style used in C:
/* #define wantFOO 1 /* To get foo feature */
#define wantBAR 1 /* To get bar feature */
/* #define wamtBAZ 1 /* To get baz feature */
It gave me a good laugh at the time.]
In any case, I have always considered the use of end_of_file
to get some kind of half-baked ability to comment out a part of a file
as an abomination (which does not mean I didn't use it and find it
useful).
-- Gunnar Blomberg
------------------------------
Date: 25 Mar 88 12:33:40 GMT
From: mcvax!enea!zyx!grzm@uunet.uu.net (Gunnar Blomberg)
Subject: behavior of read/get0 at end_of_file
In article <814@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>Just to continue with the get0 topic:
>
> The fail-at-end approach rests on an assumption
> which deserves to be made explicit, because it is false.
>
>What is the assumption? That receiving the end-of-file indication from
>an operating system indicates that there is nothing further to read in
>that stream. This is false? Yes.
>
[Lots of examples deleted]
This argumentation seems a little doubtful to me. I don't have
experience with all the systems RAO'K mentions, but (to the best of my
memory) I have never seen a use of end-of-file from the terminal that
wasn't being used to pretend that the terminal was more than one file.
Cases in point:
DEC-10 Prolog (on TOPS-20, alas):
User says [user], gives clauses and ends with ↑Z. The system
pretends that there is a file 'user' by reading from the
terminal until end-of-file is seen. As far as Prolog is
concerned the file ended at that point, and no more reading
is done from that particular file at that point.
Using the terminal as standard input in Unix:
Example: user types 'cat >foo' and then writes contents of file
on terminal, indicating end by end-of-file. As far as the
reader of that particular input is concerned the file ended at
that point, and no more reading is done from that particular
'file'.
In conclusion: I think that software conventions concerning
end-of-file from the terminal exist primarily to enable the
system/user to pretend that the terminal is more than one file. In
fact, I know of no instance where this is not so. Can somebody come
up with an example where multiple end-of-files are actually used in
one single ('conceptual') file?
-- Gunnar Blomberg
------------------------------
Date: 25 Mar 88 13:16:24 GMT
From: eagle!icdoc!ivax!cdsm@ucbvax.Berkeley.EDU (Chris Moss)
Subject: behavior of read/get0 at end_of_file
In article <801@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
rok>I find it extremely odd to call a string of length one a character.
rok> ... But it because rather more
rok>clumsy on the D machines, which have a 16-bit character set. (Can you say
rok>"Kanji"? I knew you could.)
Yes, the BSI committee is just beginning to face up to this problem,
as the Japanese have just started taking an interest...
As Richard points out, it's not much problem for a character based
definition, which I personally would favour.
rok>The fail-at-end approach forces us not only to do something special
rok>with the get0/1 in rest_identifier/3, but in everything that calls it.
rok>(In the Prolog tokeniser, there are two such callers.)
rok>
rok>The point is that if-then-elses such as Meier suggests start
rok>appearing all over the place like maggots in a corpse if you adopt
rok>the fail-at-end approach, to the point of obscuring the underlying
rok>automaton.
I think this is a fair point when looking at the definition of
lexical analysers, however...
mmeier> I must say, none of the two seems to me satisfactory. Richard's
mm> version is not portable due to the -1 as eof character.
A character definition which included a (special) end-of-file token would be
better.
mm> BSI objects that if [read/1] returns e.g. the atom end_of_file
mm> then any occurrence of this atom in the source file
mm> could not be distinguished from a real end of file.
rok>
rok>That's not a bug, it's a feature! I'm serious about that.
I don't think that is any better than most uses of that particular
argument. Sure, if you learn to live with it you can find uses for it.
rok>Before taking end_of_file away from me, the BSI committee should supply
rok>me with a portable way of exiting a break level and a reliable method of
rok>leaving test cases in a file without having them always read.
And this is the death of any standardization process! I have yet to
find the document that Richard referred to (a few days ago) when he
claimed that the BSI's mandate was to standardize Edinburgh Prolog.
It certainly hasn't been repeated in all the other formal
presentations that have been made to BSI or ISO. But if one has to
follow every wrinkle of an implementation just because it represents
(arguably) the most popular dialect, then why don't we just
appoint IBM to write all our standards for us (or Quintus or ...)?
[And who is the TRUE inheritor of the title "Edinburgh Prolog" anyway? Is
it the commercial product (formerly NIP) now being sold under that title?]
To return to the argument, I think there's a significant difference between
get0 and read. Having an end-of-file marker for read is (almost
never) used to implement finite-state-machines. Instead it is used
for repeat-fail loops.
e.g. go :- repeat,
read(Term),
(Term=end_of_file -> true; process(Term), fail).
Now in the days before tail recursion and all the other optimizations
this was inevitable. But why should we encourage this approach today?
The above clause is a good example of the trickiness of "repeat". I always
write repeat loops wrong first time and this was no exception. I put
(Term=end_of_file -> true; process(Term)), fail.
then changed it to
(Term=end_of_file -> !; process(Term)), fail.
before settling on the above version. I personally think "repeat" should
be left out of the standard (there's no penalty overhead in not having it
built-in these days anyway). Don't other people have my problem?
It would seem to encourage better programming if we allowed "get0"
(or get_file or whatever) to return an end-of-file token, and any
high-level routines to fail at end-of-file. It's not particularly
consistent, but I don't know whether that's a priority in this case.
rok>In fact, on my SUN right now I have function key F5 bound to
rok>"end_of_file.\n" so that I can get out of Prolog without running the
rok>risk of typing too many of them and logging out.
I seem to get by perfectly well by setting "ignoreeof" in my cshell!
rok>Ah, you'll say, but that's what nested comments are for!
rok>Well no, they don't work. That's right, "#| ... |#" is NOT a reliable
rok>way of commenting code out in Common Lisp, and "/* ... */" is NOT a
rok>reliable way of commenting code out in PopLog.
That seems to be the best argument for allowing end-of-line comments in
Prolog. Now where do I find the Emacs macro for commenting out all lines
between dot and mark (and removing such comments)?
Chris Moss
Disclaimer: unless I say otherwise I am expressing my personal opinions
NOT the opinions of any committee!
------------------------------
End of PROLOG Digest
********************
∂15-Jul-88 1913 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #28
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Jul 88 19:13:22 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA11243; Mon, 4 Jul 88 09:42:22 PDT
Date: Mon, 4 Jul 88 09:42:22 PDT
From: Chuck Restivo <restivo@polya.Stanford.EDU>
Message-Id: <8807041642.AA11243@polya.Stanford.EDU>
To: restivo@polya.Stanford.EDU
Subject: PROLOG DIGEST V6 #28
Date: Thursday, 5 May 1988 0:1:43-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@POLYA.STANFORD.EDU>
Reply-to: PROLOG@POLYA.STANFORD.EDU>
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #28
To: PROLOG@POLYA.STANFORD.EDU
PROLOG Digest Friday, 1 Apr 1988 Volume 6 : Issue 28
Today's Topics:
Query - Parallel Compilers,
Implementation - end_of_file & Strings & Eliza
----------------------------------------------------------------------------------------------------------------------------
Date: 23 Mar 88 14:26:19 GMT
From: mcvax!dutrun!dutesta!ignacio@uunet.uu.net (Ignacio GARCIA ALVES)
Subject: Parallel prolog compilers and interpreters
We are interested in PARALLEL PROLOG COMPILERS AND INTERPRETERS, like for
example PARLOG and CONCURRENT PROLOG.
But now the problem: WHERE CAN WE FIND THEM?
So we would like to hear the answers to the following questions:
- where can we order them?
- what are the prices?
- who has already such a compiler or interpreter to hear their experience?
- what are the hardware and software requirements?
We do have the following hardware:
- VAX, Berkeley Unix 4.1
- RT, AIX
- PC
All information is welcome either by post or email!
POST: Ignacio GARCIA ALVES & Mark KORSLOOT
Delft University of Technology
Faculty of Electrical Engineering
Section Computer Architecture
Mekelweg 4
2628 CD DELFT
THE NETHERLANDS
EMAIL: !mcvax!dutrun!dutesta!ignacio.uucp
or !mcvax!dutrun!dutesta!mark.uucp
-----------------------------
Date: 24 Mar 88 03:06:23 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Subject: behavior of read/get0 at end_of_file
I just grepped through the UNIX [UNIX is a trademark of AT&T] manuals,
and all I could find was the function feof(Stream). None of the UNIX
utilities I am familiar with uses "eof" to signify end of file.
Franz Lisp does something interesting:
(ratom [Port [Eof]])
(read [Port [Eof]])
(readc [Port [Eof]])
return the Eof argument (which defaults to nil) when you read the
end of the file, so you can get whatever takes your fancy.
> so i think we could maybe abandon the end_of_file notation of Quintus (sorry
> for you Richard, a compatibility switch could very easily turn it back anyway),
But it ***ISN'T*** a Quintus notation! This is the notation used by
DEC-10 Prolog
EMAS Prolog
C Prolog
Quintus Prolog
Stony Brook Prolog
ALS Prolog
Expert Systems International Prolog-2
AAIS Prolog (in "Edinburgh" mode only)
and doubtless many others. end_of_file IS the "de facto" standard.
Poterie's suggestions are good ones, but in order to overthrow the
de facto standard, they would have to be MUCH MUCH better, and they
aren't.
> but it is not an important point as the aim would be to discipline one's
> programming style by systematically using the test form:
> eof(Term)
> and never ever explicit the EOF term itself. Portability is great.
Beware. While Quintus Prolog offers the library predicate
is_endfile(?EndMarker)
there are other Prolog systems, such as AAIS Prolog, where there is a
predicate with a similar name which takes a Stream argument:
is_eof(+Stream)
in AAIS Prolog means "is it the case that Stream is positioned at its end?".
Yes, portability is great, but would it not be more just to reward those
people (such as SICS, Saumya Debray, ALS, and others) who have tried to
provide it, by standardising their solution?
> As a side effect, close/1 is
> not strictly necessary anymore as the following sequence does the job:
> eof(EOF), put(EOF)
Um, what about INPUT streams? And there is another reason for wanting
close/1: it will close a stream which is not the current output stream.
------------------------------
Date: 26 Mar 88 05:25:23 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Subject: End-of-file handling
In article <2403@zyx.UUCP>, bd@zyx.UUCP (Bjorn Danielsson) writes:
> I can't understand why there should be a "strait-jacket solution" to this
> kind of problem. Why not put in enough flexibility to allow for the most
> obvious cases? In Z-Prolog, (which was never designed to be Edinburgh
> compatible) the "read" predicate can handle end-of-file in three different
> ways, depending on an optional argument:
> (1) signal an error,
> (2) fail,
> (3) return a value supplied by the programmer.
>
Oh, __HOW__ I wish you were were handling the I/O part of BSI substandard!
That's EXACTLY the right sort of attitude for a standard designer.
I think that there are sound technical reasons for regarding fail-at-end
as a straight-out blunder, and I have used PL/I and Fortran enough to
convince me that end-of-file is NOT an error and shouldn't be treated
like one. (Reading *past* end-of-file is another matter, which is one of
the things I have against fail-at-end.) But a more powerful operation,
which is not perceptibly harder to implement, which will let me synthesise
the operation I want, and let BIM synthesize the operation they want,
that's exactly the right thing to do in the standard.
Oddly enough, I had intended to mention Algol 68. Files in Algol 68 are
rather interesting. One of the things you can do is say
FILE example file;
...
logical file ended OF example file :=
(FILE file parameter) BOOL: (
# return FALSE to get default action (e.g. error report) #
# return TRUE to say "corrected, please try again" #
# or jump out #
);
Interlisp does the same sort of thing:
(WHENCLOSE file 'EOF (FUNCTION (LAMBDA (file) (* action *)) ))
So even if we decide to feed this goose instead of killing it, there are
at least three options:
1. specify in each call what action to take on end of file
read(Stream, Term, EofAction)
-- This affects 'read' only.
2. specify per stream what action to take on end of file
eof_action(Stream, EofAction)
-- This could affect any form of input.
3. allow both.
One of the constraints which is of interest to Quintus is that whatever the
end of file action is, it has to make sense if the stream was being used by
C or Lisp code. The nice thing about sticking with -1 as the character
end-of-file mark and adopting option 3 is that it does this.
Note though that as I mentioned in my previous message, just because the
host operating system indicates an end-of-file condition doesn't mean that
it isn't possible to read any more from the file. (UNIX fans will know
about 'tail -f' and why it is useful...) The standard should, I said in
'84, include a predicate for testing whether the stream is really ended.
If the stream is not really ended, it should be possible to resume reading.
------------------------------
Date: 22 Mar 88 16:55:39 GMT
From: mcvax!unido!ecrcvax!bruno@uunet.uu.net (Bruno Poterie)
Subject: behavior of read/get0 at end_of_file
I do not think that having read/1 returning an atom on EOF is a bad thing.
If you take as an example certain UN*X tools, they read their input from
a file (typically stdin) until finding a line composed of a single dot.
So it is perfectly legal to submit a file which contains a dot-line in the
middle if you want only the first part to be feeded to the tool. Same thing
for Prolog, if you have a huge file full of various facts but want only say
the first 100 to be used as input in your test program, then simply add
the EOF mark before line 101. I would then prefer to have it as a directive:
...
:- eof.
so that it is not a bare fact but actually a command to the consulting tool
that it have to EOF this input source. It is then coherent with other
directives like:
...
:- [file3,file4].
...
which actually order the consulting tool to insert at this point the content
of the named files. I believe that the notation "eof" is quite standard in
the UN*X system and already in some Prolog, including as a test predicate for
this very term:
... read(Term), eof(Term) -> ...
so i think we could maybe abandon the end_of_file notation of Quintus (sorry
for you Richard, a compatibility switch could very easily turn it back anyway),
but it is not an important point as the aim would be to discipline one's
programming style by systematically using the test form:
eof(Term)
and never ever explicit the EOF term itself. Portability is great.
Now for the get0/1 [or get_char/1/2]: having it returning an otherwise
impossible value, say an atom as suggested by Micha, is ok if the returned
thing is an integer representing the ascii code [or ebcdic] of the character.
using the same term as the one returned by read/1, and consequently the same
test predicate as only mechanism to check for EOF, would greatly improve the
compactness and consistency of the i/o system. As a side effect, close/1 is
not strictly necessary anymore as the following sequence does the job:
eof(EOF), put(EOF)
Because obviously put/1 must handle the same term in the same way (I am afraid
that outputing CHAR modulo 256 would not work in this case).
I nevertheless believe that EOF == -1 is a clearer convention, returning an
object of the same type but out of the normal range of normal input, and
is already the UN*X convention. It would not force put/1 to accept it as EOF
character, as it would be outputed as: -1 modulo 256 (or 512) == 255. Passing
-1 to UN*X putchar() does not generate an EOF!
Ok, enough delirium tremens for today. My main point is: the character i/o
should provide a very low level facility, with no hypothesis about the use
which could be made of them. Using read(Term) and eof(Term) provides an
uniform, simple, elegant and portable mean of performing i/o at Prolog term
level. Using get0/1 implies you are interested in the real bits contained
in your input support, so you want to control it at a low level. Returning
the -1 value is portable and low-level, because independant of ascii or
any other character set. Alternatively, returning eof and using the same
eof(Char) test predicate would be again low-level, portable, and free of
any supposed semantic. More important, most of prolog input loops may be
adapted with this scheme at low cost. Failing at EOF, however, would mean
full rewriting of those applications and system libraries.
------------------------------
Date: 22 Mar 88 10:29:39 GMT
From: mcvax!prlb2!kulcs!bimandre@uunet.uu.net (Andre Marien)
Subject: end_of_file treatment in prolog
Sorry for being inaccurate: we should have taken the trouble of explaining what
BIMprolog's predicate eof/0 does and it is different from what Richard's
at_eof/0 does:
eof/0 succeeds only after a read/1 or get0/1 has failed because end of
file was encountered
so, let me change buggy_read into:
non_buggy_read(Term) :- bim_read(Term), ! .
non_buggy_read(end_of_file) :- eof .
actually, eof/0 is written using a predicate in_status/1 which unifies
its argument with an integer indicating the 'status' of the input stream
> end-failure approach, despite having asked Bart Demoen at the Prolog
> Benchmarking Workshop for enlightenment on this point. Again, this
Perhaps you asked Andre' Marien, but not Bart Demoen: he was not at the Prolog
Benchmarking Workshop
Now about the transformation of
s1: a -> s2.
s1: b -> s1.
s1: $ -> accept.
to a prolog procedure;
1. the textbook uses an explicit end of file marker, so it is clear that the
behavior of Cprolog's get0/1 suites better in this transformation;
still, I would rather represent a state by a predicate with arity 0 and let
it get its character itself:
s1 :- get0(X) ,
(X = a , s2 ;
X = b , s1 ;
X = -1 , true
) .
this of course with get0/1 behaving like in Cprolog
2. Now, do it with BIMprolog's get0/1, I will call it BIMget0 so that you will
always know which behavior to expect
s1 :- BIMget0(X) , (X = a , s2 ;
X = b , s1
) .
s1 :- eof .
this doesn't look very nice, but
a. I would expect that in a parser, in most states eof indicates an
error, so that error recovery must be done, which is very easy
(in prolog) by backtracking to the appropriate level (state) in the
parser; so in most states, there would be no clause like s1 :- eof.
then, on eof, s1 fails as it does on input characters different
from a or b
see Pascal : an endpoint is the endmarker, and occurrence of eof
during tokenizing means an error
see Prolog : every clause must have an endpoint; eof could only
occur after a clause
b. prolog (at least BIMprolog) is used for other things than writing
tokenizers - actually, tokenizers should not be written at all: they
should be generated - and in an administrative application written in
prolog, using BIMread or BIMget, the programmer can feel at ease:
after a successful BIMread or BIMget, he has got data; it is in a
way impossible for him to forget testing for eof, because otherwise
the execution of the program would never have gone so far
3. A more general approach can be used, using a state transition table.
The previous program can be derived from this by partial evaluation.
In the triangle puzzle problem discussion, R.O'K argued that this
approach is more general.
step_state(accept) :- ! .
step_state(From) :- BIMget0(X), !,
From : X => New,
step_state(New) .
step_state(From) :- BIMeof,
From : '$' => New,
step_state(New) .
s1: a => s2.
s1: b => s1.
s1: '$' => accept.
If eof is to be treated as an error, remove the last clause of
step_state/1.
Eof is handled in one place, in Cprolog one should add :
transit(si,-1,error) .
for all states, or write :
state(From) :- get0(X), noteof(X), !,
transit(From,X,New),
state(New) .
noteof(-1) :- !, fail .
noteof(_) .
To sum up: there is an appropriate level of testing for eof: BIMread and BIMget
(and BSIread and BSIget for that matter, to answer one of Richard's questions
and worries) allow you to do this testing of eof at these levels only, while
read and get0 of Cprolog force you to test it after every input operation
------------------------------
Date: 23 Mar 88 09:54:10 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Subject: behavior of read/get0 at end_of_file
In article <518@ecrcvax.UUCP>, micha@ecrcvax.UUCP (Micha Meier) writes:
> By the way, get0/1 does *not* exist in BSI, it uses get_char/1 instead,
> and its argument is a character, i.e. a string of length 1.
> This means that the type 'character' is inferred from
> the type 'string' (and not the other way round like in C).
> Does anybody out there know what advantages this can bring?
> It is independent on the character <-> integer encoding,
> but this only because explicit conversion predicates have
> to be called all the time.
I find it extremely odd to call a string of length one a character.
It's like calling a list of integers which contains one element an
integer. Do we call an array with one element a scalar?
I haven't commented on the BSI's get_char/1 before because for once they
have given a new operation a new name. There are two problems with it.
A minor problem is that the result being a string, they can't represent
end of file with an additional character, so the fail-at-end approach is
hard to avoid. (Not impossible.) There is an efficiency problem:
something which returns an integer or a character constant can just
return a single tagged item, but something which returns a string either
has to construct a new string every time, or else cache the strings somehow.
For example, Interlisp has a function which returns you the next character
in the current input stream, represented as an atom with one character in
its name. (Well, almost: characters `0`..`9` are represented by integers
0..9.) This was quite attractive on a DEC-20, where you could just compute
a table of 128 atoms once and for all. It wasn't too bad on VAXen either,
where the table had to have 256 elements. But it because rather more
clumsy on the D machines, which have a 16-bit character set. (Can you say
"Kanji"? I knew you could.) So the alternatives I can see at the moment
are
o construct a new string every time.
o precompute 2↑16 strings.
o cache 2↑8 strings, and construct a new string every
time for Kanji and other non-Latin alphabets.
o not support Kanji or other non-Latin alphabets at all.
(Can you say "Cyrillic"? How about "Devanagari"? You may need the
assistance of a good dictionary; I used to mispronounce "Devanagari",
and probably still do.)
I wrote that
> >For example, the arcs
> > s1: a -> s2.
> > s1: b -> s1.
> > s1: $ -> accept.
> >would be coded like this:
> > s1(0'a) :- get0(Next), s2(Next).
> > s1(0'b) :- get0(Next), s1(Next).
> > s1(- 1) :- true.
Meier says that
> In his tutorial to the SLP '87 Richard has taken another
> representation of a finite automaton which is more appropriate:
> s1 :-
> get0(Char),
> s1(Char).
>
> s1(0'a) :-
> s2.
> s1(0'b) :-
> s1.
> s1(-1) :-
> accept.
There wasn't time to go into this in detail in the tutorial, but it
should be obvious that the first approach is more general: in particular
it can handle transitions where (perhaps because of context) no input is
consumed, and it can handle lookahead.
> Such representation can
> be more easily converted to the BSI's variant of get:
> s1 :-
> % do the corresponding action
> ( get0(Char) -> s1(Char)
> ;
> accept
> ).
This doesn't generalise as well as the end-marker version.
Here is the kind of thing one is constantly doing:
rest_identifier(Char, [Char|Chars], After) :-
is_csymf(Char),
!,
get0(Next),
rest_identifier(Next, Chars, After).
rest_identifier(After, [], After).
See how this code can treat the end marker just like any other
character: because it doesn't pass the is_csymf/1 test (copied from
Harbison & Steele, by the way) we'll pick the second clause, and there
is no special case needed for an identifier which happens to be at the
end of a stream.
The fail-at-end approach forces us not only to do something special
with the get0/1 in rest_identifier/3, but in everything that calls it.
(In the Prolog tokeniser, there are two such callers.)
The point is that if-then-elses such as Meier suggests start
appearing all over the place like maggots in a corpse if you adopt
the fail-at-end approach, to the point of obscuring the underlying
automaton.
> I must say, none of the two seems to me satisfactory. Richard's
> version is not portable due to the -1 as eof character.
If the standard were to rule that -1 was the end of file character,
it would be precisely as portable as anything else in the standard!
In strict point of fact, the Prolog-in-Prolog tokeniser was written
in DEC-10 Prolog for DEC-10 Prolog, and used 26 as the end of file
character, and 31 as the end of line character. It took 5 minutes
with an editor to adapt it to Quintus Prolog. I wish C programs
written for UNIX took this little effort to port!
> for a Prolog system it is better to have get0/1 return
> some *portable* eof (e.g the atom end_of_file, for get0/1
> there can be no confusion with source items) instead of
> some integer.
It is important that the end-of-file marker, whatever it is, should be
the same kind of thing, in some sense, as the normal values, so that
classification tests such as is_lower/1, is_digit/1, and so on will
just fail quietly for the end-of-file marker, not report errors. Since
end of file is rare, we would like to test the other cases first.
Pop-2 on the Dec-10 returned integers almost all the time, except that
at the end of a stream you got an end-of-file object which belonged to
another data type (there was only one element of that data type, and it
printed as ↑Z). This was in practice a major nuisance, because before
you could do anything other than an equality test with the result, you
had to check whether it was the end of file mark.
I have been giving out copies of the Prolog-in-Prolog tokeniser to show
how easy it is to program character input with the Edinburgh Prolog
approach. If someone would give me a tokeniser for BSI Prolog written
entirely in BSI Prolog using the fail-at-end approach, and if that
tokeniser were about as readable as the Prolog-in-Prolog one, that would
go a long way towards convincing me that fail-at-end was a good idea.
> BSI objects that if [read/1] returns e.g. the atom end_of_file
> then any occurrence of this atom in the source file
> could not be distinguished from a real end of file.
That's not a bug, it's a feature! I'm serious about that. At Edinburgh,
I had the problem that if someone asked me for help with Prolog, they
might be using one of four different operating systems, where the end
of file key might be
↑Z
or ↑D
or ↑Y
or something else which I have been glad to forget.
No problem. I could always type
end_of_file.
to a Prolog listener, and it would go away. Oh, this was so nice!
In fact, on my SUN right now I have function key F5 bound to
"end_of_file.\n" so that I can get out of Prolog without running the
risk of typing too many of them and logging out.
Another thing it is useful for is leaving test data in a source file.
One can do
<declarations>
<clauses>
end_of_file.
<test cases>
and include the test cases in the program or not just by moving the
end_of_file around.
Ah, you'll say, but that's what nested comments are for!
Well no, they don't work. That's right, "#| ... |#" is NOT a reliable
way of commenting code out in Common Lisp, and "/* ... */" is NOT a
reliable way of commenting code out in PopLog. But end_of_file, in
Edinburgh Prolog, IS a reliable way of commenting out the rest of the file.
> In this case, a remedy would be the introduction of
Prolog needs a remedy for end_of_file like Elizabeth Schwarzkopf
needs a remedy for her voice.
Before taking end_of_file away from me, the BSI committee should supply
me with a portable way of exiting a break level and a reliable method of
leaving test cases in a file without having them always read.
------------------------------
Date: 24 Mar 88 08:58:35 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Subject: behavior of read/get0 at end_of_file
Just to continue with the get0 topic:
The fail-at-end approach rests on an assumption
which deserves to be made explicit, because it is false.
What is the assumption? That receiving the end-of-file indication from
an operating system indicates that there is nothing further to read in
that stream. This is false? Yes.
Let's ignore 4.2BSD sockets, V.3 Streams, non-blocking I/O, VMS
concatenated files, and other esoterica which one doesn't expect
BSI Prolog to cope with. Let's just consider terminals.
In Tops-10 (home of DEC-10 Prolog):
end-of-file from the terminal is a software convention (↑Z).
You can just keep reading from the terminal after that, and
in fact that's exactly what DEC-10 Prolog does.
In UNIX (original home of C Prolog):
end-of-file from the terminal is a software convention
(EOF character typed after an empty line).
You can just keep reading from the terminal after that, and
in fact that's exactly what C Prolog does.
In VM/CMS, using SAS Lattice C
end-of-file from the terminal is a software convention
(some magic string, which defaults to "EOF", but it is
trivially easy for a program to change it -- use afreopen()).
I believe that you can keep reading from the terminal after
that, but I haven't tried it myself.
On a Macintosh, using ALS Prolog
end-of-file from a window is a software convention
(you click on "End of File" in the "Edit" menu).
All windows and streams remain live after that, and
you can just keep reading, and that's what ALS Prolog does.
On a Xerox Lisp Machine, using Xerox Quintus Prolog
end-of-file from a TEXEC window is a software convention.
All windows and streams remain live after that, and
you can just keep reading, and that's what XQP does.
[The sample of Prologs is not of interest here; my point is that there
are several *operating systems* with this characteristic.
]
So the rule actually followed in Edinburgh-compatible Prologs is that
- the sequence of characters codes returned by get0/1 is
the sequence of characters delivered by the source
- with the end-of-file marker inserted every time the
host indicated the end-of-file condition
- Prolog receives through get0/1 as many characters and as many
end-of-file markers as there are; any attempt to read past the
end of this union stream is an error. Not a failure, an error.
It happens that when you are reading from disc files, most operating
systems will indicate the end of file condition once.
Are terminals the only kind of file for which multiple end-of-file
conditions are plausible? No. The convention for tapes is that a
single tape-mark (usually reported as an end-of-file condition) is
merely a separator; a tape as such is terminated by a double tape-mark.
Thus a Prolog program copying one tape to another (this is a reason why
we might want put(-1) NOT to close a file; if it does anything special
on a tape it should be to write a tape-mark) might want to keep reading
after seeing an end-marker.
------------------------------
Date: 24 Mar 88 15:29:47 GMT
From: mcvax!ukc!dcl-cs!simon@uunet.uu.net (Simon Brooke)
Subject: Strings
In article <776@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>Xerox Lisp uses lists for bignums to this very day.
Yes, true. But please don't assume this means it is efficient. For
example, I recently benchmarked a Xerox 1186 running Interlisp (Koto)
against the new Acorn Archimedes running Arthur Norman's Cambridge Lisp.
Generally the Arch was a bit faster, reflecting the simpler lisp and
faster processor. But running (fact 1000) it was 321 (three hundred and
twenty one) times faster - and this must reflect grotesque inefficiency in
Xerox' bignum code.
------------------------------
Date: 24 Mar 88 18:35:05 GMT
From: eagle!icdoc!doc.ic.ac.uk!cdsm@ucbvax.Berkeley.EDU (Chris Moss)
Subject: Strings
I haven't contributed to the string discussion because I don't believe I
know all the answers. But I do have strong reservations about the current
Edinburgh implementations. Let me air them:
1. They don't get printed properly by "write". I don't like seeing
"Prolog" come out as [80,114,111,108,111,103]. OK, I can define a
"writestring", but not use it within a bigger structure without pain.
Now here's an odd thing: there is no writestring routine in the Quintus
library that I can discover! Not in the built-ins or the (extensive)
library!
What does that tell us about the use of strings? It suggests to
me that people actually always use atoms for this purpose, and somewhere
in their code is an implicit definition:
writestring(String) :- name(Atom,String),write(Atom).
Note that in most systems this involves an entry in the symbol table
(reasonably slow) and a limit of 256 (or maybe 512) characters.
MuProlog DOES print out "Prolog" as a string, wherever it occurs.
Presumably it has to scan the list first. It uses list format whenever
there is a integer outside the range 32-127 in the list (it also gets tabs
right tho I don't understand why it finishes at 127 not 126). That's a
pretty good heuristic, tho I can imagine it going wrong on occasions. e.g.
if I read in a clause over several lines the string will contain newlines,
so my DCG debugging will still look horrid!
2. I don't like having ASCII values in my programs. With a certain amount
of discipline and inefficiency one can get round that, by saying, for
instance:
lowercase(X) :- "a"=[A], "z"=[Z], X>=A, X=<Z.
but it's not an ideal solution (tho close to normal arithmetic habits in
Prolog). These type of routines tend to be efficiency sensitive.
OK, there is the 0'a notation (another way of writing 97 if you're using
ASCII). Now that DOESN'T work in MuProlog, or Poplog or ...
On efficiency I mostly agree with Richard. I too like strings to be lists,
and can't see the real benefits of a string type, though you don't tend to
miss what you never had!
So, what I would like to see is not a string type but a CHARACTER type.
Small integers work in Ed-Prolog mainly because they're efficient for get
and put -- there's no symbol table lookup. It would be nice to treat
single character atoms as their ASCII value, but that's wrong because one
does want to hang things off atoms. So they would have to be a separate
data type. As far as notation is concerned I have no better suggestion
than 0'a tho I don't much like it.
Now I don't object to Pascal's ORD (tho Modula II's ORD is TERRIBLE.
It is defined as CARDINAL so one usually has to say VAL(INTEGER,ORD("a"))).
But one-way transfers aren't much of a problem semantically, so I
wouldn't object to the C solution, which allows them to be used in arithmetic
contexts. e.g. Num is Ch-0'0 or Letter =<0'z.
Thus the main difference with the present systems would be:
1. 0'a wouldn't unify with 97. (I assume)
2. write(0'a) would print out 0'a.
3. write("abc") or write([0'a,0'b,0'c]) would print out as "abc".
4. One would need a "CHR" function (but not ORD) in arithmetic
expressions.
The question is, "is it worth the change"? For my pennyworth the answer
is "yes". NOT having a character type makes Prolog as archaic as Fortran
IV in computer-science terms. I don't much like the string type idea. And
if you say "you proposed it" you're wrong. I've only been concerned with
syntax and semantics, not the built-in-predicates (there are limits to the
number of committees any sane person can attend!). Strings have been mostly
discussed in the BIPs meetings. Most of my suggestions at main committee
meetings have been ignored! When it comes to the semantics one needs a
character type even in the present proposal.
The biggest anti-argument is that all sorts of Prolog programs might break
in weird ways because of difference 1. I don't know the answer to that.
-- Chris Moss
------------------------------
Date: 21 Mar 88 08:45:07 GMT
From: otter!kers@hplabs.hp.com (Christopher Dollin)
Subject: Prolog implementations in Lisp
Pop11 is like Lisp[*3] in that it has dynamic typing, dynamic store allocation
with garbage collection, first class (really, *1st*, not 1.5st) procedures,
lexical scoping, and run-time access to the compiler. It is unlike Lisp in that
it has a concrete syntax, open stack, partial application, user-defined
datatypes that aren't just funny uses of vectors or lists, and coroutines.
I think I'll go and lie down. Notefeet follow.
[*1] Systems Designers market Poplog in the USA and UK for commercial clients.
Sussex University deal with educational establishments in the UK, and
Robin Popplestone does so in the USA.
[*2] OK, quite a lot really.
[*3] When I say Lisp I mean Vulgar - sorry, Common - Lisp.
Regards,
-- Kers
-------------------------------
Date: 25 Mar 88 04:39:20 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Subject: My views on developing a PROLOG standard
In article <240@gould.doc.ic.ac.uk>, cdsm@ivax.doc.ic.ac.uk (Chris Moss) writes:
> Richard's certainty that the
> Prolog world begins and ends with Edinburgh is not shared in France!
I have no such certainty. I think the Prolog world includes Israel,
Japan, Australia, Portugal, the USA, Hungary, China[*], and all sorts of
places. The plain fact of the matter is that there are two sorts of
Prolog systems: ones whose authors have tried to provide some sort of
compatibility with other Prologs, and ones whose authors have let their
imaginations rip. What the compatible Prologs are compatible with is
not Prolog-II or Waterloo Prolog, but Clocksin&Mellish.
[*] I am credibly informed that the PRC uses an unauthorised translation
of Clocksin & Mellish as the main Prolog text, so presumably the
French Prologs are of small concern to them.
------------------------------
Date: 20 Mar 88 20:47:39 GMT
From: lagache@violet.Berkeley.EDU (Edouard Lagache)
Subject: An Eliza-like problem solving assistant (400+ lines).
The following program is the mockup of the Eliza-like problem solving
assistant that was demonstrated at the March 10 meeting of the PROLOG Forum.
The program is the result of 3 late night work, and NO claims of
correctness or efficiency are expressed on implied. On the contrary,
suggestions for expansion or improvement are most welcome. As stated
earlier, it is hoped to turn this program into a group project, so
we hope that there is plenty of room for expansion!
There are some calls to my imfamous PROLOG libraries. The 'window'
and 'set_attribute' calls will only work on a Texas Instruments PC,
so I leave it to you to omit, or port these calls to your system.
There is one call to the predicate 'nthelem', I have enclosed a copy
of the predicate at the end of the file. There may be other calls
that I have forgotten, if so let me know and I will provide the needed
code.
Hack to your hearts delight!
-- Edouard Lagache
/* File: 'consulta.pro' */
/******************************************************************************/
/* */
/* An A.I. Consultant for PROLOG Programmers */
/* */
/* This program is intended to serve as a "intelligent consultant" */
/* for PROLOG programs to turn to when encountering some impasse in a */
/* programming project. The program is based on the "Eliza" program, but */
/* it designed to provide comments that might foster the user to "solve" */
/* his/her own problem. */
/* */
/* A collaborative project of the PROLOG Forum. */
/* Release - 1.00, March - 1988, Copyright(C) 1988, The PROLOG Forum */
/* */
/* Credits: The concept of an "Eliza" type program to help users with */
/* problem solving was first proposed (as far as we know) by */
/* Professor Charles Woodson of the School of Education at */
/* U.C. Berkeley. He also built a small system in LISP for the */
/* purposes of demonstrating the concept to members of his LISP */
/* programming course. */
/* */
/******************************************************************************/
/*>> 'gethelp' is the routine that the user can call to get access to the <<*/
/*>> system. E. Lagache, Ver-1.0, 3/88 <<*/
gethelp :- tell('_WINDOWS'), make_window(0,15,14,64), set_attribute(magenta),
clear_screen, set_attribute(white),
prtstr("Please describe your problem, type 'quit.' to resume work"),
nl, converse, close_window, tell(user).
/*>> 'converse' is the main "looping" routine. It takes a list of words <<*/
/*>> and searches for keywords. Then it generates a response based on <<*/
/*>> keywords. The responses are randomized to make the system more <<*/
/*>> "humanlike". E.L., Ver-1.0, 3/88 <<*/
converse :- set_attribute(white), prtstr("<>-> "), set_attribute('yellow'),
read_sentence(Request), nl, remove_duplicates(Request,Request1),
make_reply(Request1,Reply), set_attribute(cyan),
print_reply(Reply), nl, continue(Request1).
/* continue makes the recursive call to 'converse' if the user doesn't want */
/* quit */
continue(['quit','.']) :- set_attribute(white), pause.
continue(_) :- converse.
/* 'pause' uses the interval function to simply carry out some time consuming */
/* task to make a delay between the exit prompt, and the closing of the */
/* window. */
pause :- interval(1,X,10), fail.
pause.
/* 'print_reply' simply prints out the list of items recursively */
print_reply([]).
print_reply([Item|Rest]) :- print(Item), put(32), print_reply(Rest).
/*>>------------------------------------------------------------------------<<*/
/*>> 'make_reply' generates a response to a keyword in the users input text <<*/
/*>> it keeps a list of keywords and appropriate responses, and chooses one <<*/
/*>> randomly to provide a "natural" appearance. <<*/
/*>> E. Lagache, Ver - 1.0, 3/88 <<*/
/* Exit comment */
make_reply(['quit','.'],['Thank','you','I','hope','these','comments','were',
'useful.']
).
/* Main test, select some set of keywords, test if they match, if so succeed */
/* otherwise fail and look at another possibility. */
make_reply(Sentence,Reply) :- word_class(Keywords,Responses),
intersection(Keywords,Sentence,List),
List \== [], !, length(Responses,Top),
irandom(1,Top,Number),
nthelem(Responses,Number,Reply).
/* if no keywords are found, then use default responses */
make_reply(_,Reply) :- default_responses(Responses), length(Responses,Top),
irandom(1,Top,Number), nthelem(Responses,Number,Reply).
/* 'remove_duplicates' returns a list that contains only one of each item. */
/* This is necessary for the 'intersection' predicate, and makes the search */
/* less time consuming. E.L. 3/88 */
remove_duplicates([],[]).
/* First case, don't copy duplicate items */
remove_duplicates([Item|Rest],NewRest) :- member(Item,Rest), !,
remove_duplicates(Rest,NewRest).
/* If not duplicated, then copy */
remove_duplicates([Item|Rest],[Item|NewRest]):- remove_duplicates(Rest,NewRest).
/* 'intersection' return true if one of the keywords was found among the */
/* words typed in. From C&M page 154 */
intersection([],X,[]).
intersection([X|R],Y,[X|Z]) :- member(X,Y), !, intersection(R,Y,Z).
intersection([X|R],Y,Z) :- intersection(R,Y,Z).
/*>> 'irandom' returns a integer in the range specified by the first two <<*/
/*>> arguments to the predicate, E. Lagache, Ver-1.0, 3/88 <<*/
/*>> Values for computation taken from the first edition of "Oh Pascal" <<*/
/*>> By Clancy and Cooper (page-227). <<*/
irandom(Lower,Upper,Number) :- get_seed(Seed),
Start is (25173*Seed + 13849) mod 65536,
Number is (Start mod (Upper - Lower)) + Lower.
/* 'get_seed' will in general be an implementation specific predicate. */
/* For ADA PROLOG, 'get_seed' will return the number of logical inferences */
/* so far made, using the ADA specific 'licount' predicate */
get_seed(Seed) :- licount(Seed).
/*>>---------------------------------------------------------------------<<*/
/*>> 'read_sentence' is a routine to take user input and make a list of <<*/
/*>> atoms out of it. It is slightly modified from Clocksin & Mellish <<*/
/*>> page 104. <<*/
read_sentence([W|Wa]) :- get0(C), readword(C,W,C1), restsent(W,C1,Wa).
/* Given a word and the character after it, read in the rest of the sentence */
restsent(W,_,[]) :- lastword(W),!.
restsent(W,C,[W1|Wa]) :- readword(C,W1,C1), restsent(W1,C1,Wa).
/* Read in a single word, given initial character, and remembering what */
/* character came after that word. */
readword(C,W,C1) :- single_character(C), !, name(W,[C]), get0(C1).
readword(C,W,C2) :- in_word(C,NewC), !, get0(C1), restword(C1,Cs,C2),
name(W,[NewC|Cs]).
readword(C,W,C2) :- get0(C1), readword(C1,W,C2).
/* continue process of stringing characters of the same word together */
restword(C,[NewC|Cs],C2) :- in_word(C,NewC), !, get0(C1), restword(C1,Cs,C2).
restword(C,[],C).
/* These characters form words on their own */
single_character(44). /* , */
single_character(59). /* ; */
single_character(58). /* : */
single_character(63). /* ? */
single_character(33). /* ! */
single_character(46). /* . */
/* These characters can appear within a word */
/* the second in_word clause converts letters to lower case */
in_word(C,C) :- C>96, C<123. /* 'a' to 'z' */
in_word(C,L) :- C>64, C<91, L is C+32. /* 'a' to 'z' */
in_word(C,C) :- C>47, C<58. /* '0' to '9' */
in_word(39,39). /* '\'' */
in_word(45,45). /* '-' */
/* These words terminate a sentence */
lastword('.').
lastword('!').
lastword('?').
/*>>-----------------------------------------------------------------------<<*/
/*>> 'word_class' and 'default_responses' contain the text that will be <<*/
/*>> presented to the user. 'word_class' also contains the list of <<*/
/*>> keywords, that will be used to decide if this type of response is <<*/
/*>> appropriate. <<*/
/* --------------------- Programming specific keywords -------------------- */
/* Words related to failure to get the file to consult properly */
word_class([consult,consulting,compile,compiling,load,loads,loading],
[
['Do',you,know,at,what,location,the,problem,'is?'],
['Could',the,problem,be,at,a,different,place,from,where,the,
error,message,is,'reported?'
],
['What',sort,of,diagnostic,message,did,the,system,'give?'],
['What',sort,of,problems,could,have,caused,this,'situation?'],
['Is',there,another,way,you,could,arrange,your,file,that,might,
make,it,easier,to,find,the,'problem?'],
]
).
/* Problems with incorrect output */
word_class([output,print,prints,printing,write,writes,writing,printout],
[
['What',sort,of,output,were,you,'expecting?'],
['What',kind,of,output,did,you,actually,get,'(if','anything)?'],
['How',could,you,modify,your,program,to,get,more,information,
about,this,'i/o','problem?'
],
['Can',you,see,where,in,the,program,the,bug,must,be,'located?'],
['How',could,you,further,localize,the,source,of,the,incorrect,
'output?'
]
]
).
/* Input problems */
word_class([input,read,reads,reading],
[
['How',do,you,that,the,problem,is,caused,by,incorrect,input,
'routines?'
],
['How',could,you,modify,your,program,to,get,more,information,
about,this,'i/o','problem?'
],
['How',could,you,further,localize,the,source,of,the,incorrect,
input,'behavior?'
],
['How',could,you,test,these,input,routines,in,'isolation?'],
]
).
/* flow of control problems */
word_class([infinite,loop,recursion,stepping,trace,tracing],
[
['Where',is,the,last,place,that,you,know,your,program,was,running,
'correctly?'
],
['How',do,you,know,that,the,program,is,not,behaving,as,it,
'should?'
],
['Which',predicates,could,have,caused,this,'phenomenon?'],
['Is',there,any,way,that,you,could,isolate,the,predicates,that,
are,at,'fault?'
],
]
).
/* Error word */
word_class([error,warning,failure,diagnostics],
[
['Can',you,isolate,the,error,to,one,'place?'],
['Can',you,find,a,reasonable,interpretation,for,these,
diagnostics
],
['Have',you,encountered,similar,sorts,of,messages,in,the,
'past?'
],
['What',sort,of,information,would,allow,you,to,deal,with,this,
'message?'
],
]
).
/* Logical errors */
word_class([infer,inference,deduce,deduction,entails,entailment],
[
['What',should,have,the,system,'deduced?'],
['What',was,the,last,inference,that,you,know,was,'correct?'],
['How',do,you,know,that,the,inference,was,in,fact,incorrect,
'(given',the,systems,actual,'configuration)?'
],
['What',sort,of,database,condition,could,have,caused,the,
observed,'deductions?'
]
]
).
/* Bug talk */
word_class([bug,malfunction,wrong,incorrect,incomplete,unexpected],
[
['How',do,you,know,you,have,a,'bug?'],
['Where',is,the,last,place,that,you,know,your,program,was,
functioning,'correctly?'
],
['What',program,behavior,where,you,'expecting?'],
['What',indicates,that,something,is,'wrong?'],
['What',occurred,that,was,not,'expected?'],
['What',information,would,you,need,to,isolate,the,'bug?'],
['what',would,you,need,to,know,to,locate,the,'malfunction?'],
['What',tests,could,you,perform,to,get,at,the,'problem?'],
]
).
/* ----------------- Problem solving keywords ------------------------- */
/* Alternatives */
word_class([option,options,alternatives,possible,possibilities],
[
['What',alternatives,have,you,already,'tried?'],
['Are',there,other,possibilities,that,you,might,'consider?'],
['Which',options,have,you,already,'tried?'],
['Might','I',suggest,that,you,take,a,new,look,at,your,
'alternatives.'
],
]
).
/* Reflection, on previous work */
word_class([tried,attempted,thought],
[
['What',have,you,done,in,the,past,in,such,'situations?'],
['Tell',me,which,approaches,you,have,already,'tried?'],
['What',have,you,attempted,'previously?'],
['What',have,you,done,here,that,you,might,want,to,do,differently,
in,the,'future?'
]
]
).
/* Strategic problem solving, evaluating plans */
word_class([try,attempt,do,complete,investigate,think,thinking],
[
['How',will,trying,this,help,you,out,of,your,'impasse?'],
['What',can,you,learn,from,doing,'this?'],
['Are',you,sure,that,there,is,not,a,more,productive,investigation,
that,you,could,'make?'
],
['Are',there,better,ways,to,get,the,information,you,need,to,solve,
this,'problem?'
],
]
).
/* -------------------------- Human Psychology words ----------------------- */
/* stuck words */
word_class([stuck,stopped,impasse],
[
['Perhaps',you,should,reflect,back,on,the,various,'possibilities.'
],
['There',must,be,alternatives,that,you,have,not,'considered.'],
['I',suggest,that,you,step,back,from,the,problem,and,review,
what,you,have,'tried.'
],
]
).
/* "down" words */
word_class([depress,depressing,depressed,frustrating,frustrated,mad,annoy,
annoyed,annoying
],
[
['It',is,not,a,good,idea,to,get,worked,up,about,a,'program.'],
['One',should,not,take,this,too,'seriously,',after,all,it,is,
only,a,'program.'
],
['If',this,task,is,getting,to,you,perhaps,you,should,take,a,break,
and,come,back,to,it,'later.'
],
['Perhaps',you,have,been,working,too,long,on,this,one,'problem,',
maybe,you,should,take,a,'break.'
],
['Do',you,tell,me,that,this,program,is,getting,to,'you!'],
['Well',nobody,said,that,programming,was,'easy.'],
['Do',not,get,worked,up,over,'this,','after,all,',no,program,that,
is,interesting,is,easy,to,'write.'
]
]
).
/* "Bad" words (should this sort of thing be censored!?!) */
word_class([fuck,fucking,shit,shitty,damn,screw,screwed,hell],
[
['Well','I',hope,that,relieves,your,'aggressions;',now,can,
we,get,back,to,'work?'
],
['I',am,glad,you,know,'profanity;',unfortunately,this,system,
only,understands,'PROLOG!'
],
['Yes,','yes,',profanity,is,the,language,that,all,programmers,
know,'best!'
],
['If',you,can,not,say,anything,more,'constructive,',perhaps,
you,should,take,a,break,and,come,back,to,this,'problem.'
],
['Sorry',that,language,is,not,in,my,'vocabulary!'],
]
).
/* Help words */
word_class([help,assistance,explain,explanation],
[
['In',what,area,do,you,need,some,'assistance?'],
['Can',you,be,more,specific,about,what,sort,of,help,you,'need?'],
['Exactly',what,sort,of,information,do,you,'seek?'],
['In',what,way,may,'I',be,of,'assistance?'],
['What',kind,of,advice,do,you,'need?'],
['Exactly',in,what,area,do,you,need,an,'explanation?'],
['Please',tell,me,background,about,your,'problem?'],
['Could',you,further,elaborate,on,the,type,of,problem,you,are,
'having? '
]
]
).
default_responses([
['Please','continue.'],
['Could','you','say','more','about','your','problem.'],
['I','would','like','to','hear','some','more','specifics.'],
['Could','you','please','elaborate','on','one','aspect',
'of','your','problem.'
],
['Is',there,anything,else,that,you,know,about,this,
'problem?'
],
['I',do,not,quite,understand,the,'situation;',could,you,
elaborate,it,for,'me?'
]
]
).
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'nthelem' returns the element in the */
/* 'Index' place of the list. */
/* */
/* E. Lagache, Vers. - 1.00, Dec - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
nthelem([],_,error):- !, fail. /* fail if list is smaller than index */
nthelem([Item|_],1,Item):- !. /* return item */
nthelem([X|Rest],NewIndex,Item):- Index is NewIndex-1,nthelem(Rest,Index,Item).
/* end file consulta.pro */
------------------------------
Date: 24 Mar 88 02:37:00 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Subject: An Eliza-like problem solving assistant (400+ lines).
In article <7845@agate.BERKELEY.EDU>,
lagache@violet.berkeley.edu (Edouard Lagache) distributed
an "Eliza-like problem solving assistant".
(1) In the tables at the end of the program, the pattern
word_class([...],
[
[...],
...
[...],
*--------------------↑
]).
occurs quite often. While C allows extra commas in initialisers,
many Prolog systems will be unhappy about that extra comma.
(2) In order to test whether any of a given list of Keywords occurs in
a given Sentence, the program does
intersection(Keywords, Sentence, List),
List \== [],
This is correct, but there isn't a lot of point in constructing List.
A more efficient approach (effiency is not a concern in this program)
would be to call
intersect(Keywords, Sentence)
where for example
intersect(Set1, Set2) :-
member(X, Set1),
member(X, Set2),
!.
(3) I thought I'd try the program. This is what I got:
Please describe your problem. Type 'quit.' to resume work.
e> My nematodes have been eaten by the peripatus.
Could you say more about your problem.
e> Yes.
Could you please elaborate on one aspect of your problem.
e> Well, the peripatus crawled out of its box last night, and it got into
e> another box on the same bench, where we keep nematodes, and well, it
e> ate the lot of them.
Is there anything else that you know about this problem?
e> I suppose there are two problems, really. One problem is how do I
e> stop this sort of thing in the future, and the other is where do I
e> get some more nematodes right now. I want your help with the second
e> part of the problem.
What can you learn from doing this?
e> From doing WHAT?
Could you say more about your problem.
e> I just told you everything there was to say.
Could you say more about your problem.
e> You're getting a bit repetitious, aren't you?
I do not quite understand the situation; could you elaborate it for me?
e> Gods below, what is there to understand? I need some nematodes, I
e> had some nematodes, but Hodgkins' wretched peripatus ate them.
Is there anything else that you know about this problem?
e> Oh forget it.
Could you say more about your problem.
e> quit.
In case you were wondering, the e> lines do make sense.
(4) Part of the reason for the frustrating and unhelpful nature of the
conversation shown is that the program is not Eliza-like. One of
the things that Eliza would do is pick up phrases of yours and
throw them back at you. For example, after my third input, an
Eliza-like program might say
Tell me more about the box.
↑↑↑↑↑↑↑----- copied from input
or after the last input but two,
Why did Hodgkins' wretched peripatus eat them?
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑ transformed input
------------------------------
End of PROLOG Digest
********************
∂15-Jul-88 2049 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #27
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Jul 88 20:49:14 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA26706; Thu, 7 Jul 88 12:07:20 PDT
Date: Thu, 7 Jul 88 12:07:20 PDT
From: Chuck Restivo <restivo@polya.Stanford.EDU>
Message-Id: <8807071907.AA26706@polya.Stanford.EDU>
To: restivo@polya.Stanford.EDU
Subject: PROLOG DIGEST V6 #27
Date: Wed, 4 May 1988 0:4:41 PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@POLYA.STANFORD.EDU>
Reply-to: PROLOG@POLYA.STANFORD.EDU>
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #27
To: PROLOG@POLYA.STANFORD.EDU
PROLOG Digest Friday, 1 Apr 1988 Volume 6 : Issue 27
Today's Topics:
Implementation - Trilogy & Destructive Assignments,
& Simple Problem & end_of_file,
& BSI Standard & A Wager
----------------------------------------------------------------------------------------------------------------------------
Date: 23 Mar 88 19:44:15 GMT
From: pacbell!att-ih!alberta!ubc-cs!voda@AMES.ARC.NASA.GOV (Paul Voda)
Subject: Compilation in Trilogy
Here is the answer formulated in a slightly more general setting:
The modes and types of Trilogy permit the native code compilation
of programs in such a way that there are no run-time tags on
most of the values, neither there are any reference counters.
The decision when to copy out and when to share the
values of input-output variables is done by a compile
time data-flow analysis. Similarly, the compiler of Trilogy checks whether
the output variables are assigned values in all branches of a predicate
(whether all input-output variables are initialized). There
is also a check to see that if-then-elses do not backtrack
(either before thens or among the branches), e.g.
if x = 1 | x = 2 then
x <> 1 & P(x)
else
......
end
The above is dissalowed by the compiler if x is output or
symbolic (logical), but is OK if x is input or input/output.
Thus we can guarantee that the negation of the formula
before a then is always properly computable.
Consequently if-then-elses and the formulas before thens
are compiled without any settings of choice points. We are
just releasing a version where non-backtracking ors (|)
(implemented by jumps instead of choice points) are permitted
in procedures (this is useful for the writing of the Trilogy
counterparts of Pascal's boolean functions).
There are two situations where the run-time tags on Trilogy values
are present:
1) the tags discriminating the union values, these should
be also present in Pascal programs.
For instance, the universal type U of all Trilogy's values has a
form of a union:
U = R(R) | S(S) | P(U,U)
The tags R(eal), S(tring), and P(air) are thus present in the
values of U variables.
If a value is not of a union type (tuple, list, array,
integer, enumerated-type etc.) then it contains no tags,
except of course the tags of any of its union constituents.
2) When a variable is of symbolic (logical) mode then Trilogy
uses the type specific tags to identify the constraints
attached to the variable (=, <, <>, etc.).
Because of the typing, modes, pred/proc modifiers and a quite extensive
data-flow analysis the compiler of Trilogy produces a procedural
code of Pascal-like quality while offering all the high-level
comfort of symbolic values with their associated constructors
and destructors as we know it from Prolog.
------------------------------
Date: 16 Mar 88 23:35:51 GMT
From: sanjay@arizona.edu (Sanjay Manchanda)
Subject: Logic of Database Updates
I have worked on doing database updates in Prolog in a "logical"
fashion. A database update is essentially an assignment on the
database. If we are going to update the database, why not first
develop a logic for reasoning about database assignments, and then
mechanize it in the true logic programming tradition? A dynamic
logic is a reasonable choice for this task, since dynamic logics
were developed to reason about programs which explicitly manipulate
their state (i.e. do assignment). I have developed a dynamic
logic for reasoning database updates that doesn't look much like the
dynamic logic's that you may have seen, but it leads to a simple
extension of Prolog.
Instead of going into the logic, I will briefly explain the extension of
Prolog. Richard introduced it rather well in a previous
message, so let me borrow some of his words.
>Roughly speaking, there are three classes of predicates:
>
> pure predicates (don't depend on things that change)
>
> state predicates (depend on things that change, but change nothing)
>
> transition (or dynamic) predicates (express a relation between states)
>
>For example, we might say
>
> p(X) :-
> <-fred(X)> q(X).
>
>p(X) is true in a world W if there is a world W1 such that
> -(fred(X), W, W1) -- roughly, retract
>and q(X) is true in W1.
>
>Note that this doesn't change W.
There are two sets of predefined dynamic predicates, +p and -p for
every pure predicate p. Actually, to avoid some thorny
implementation and semantic problems, p is restricted to be a pure
predicate that is defined entirely by ground Prolog facts. For
obvious reasons, such a predicate is called a database predicate.
New dynamic (or transition) predicates can be defined by means of
Update Rules. For example, we might say
add_flight(Fno, Src, Dest) <--
airport(Src), airport(Dest),
<+flight(Fno, Src, Dest)>.
The use of the `<--' instead `:-' signals that a dynamic predicate is
being defined. Here the semantics of add_flight(Fno, Src, Dest) is
a transition from a world W to a world W1, such that (airport(Src),
airport(Dest)) is true in W, and W1 is obtained from W by adding
the fact flight(...) to W. Thus, viewed as an operator, + is
roughly equivalent to assert.
The rule may be used in a top level query like:
:- <add_flight(20, 'LA', 'OHARE')>reachable('LA', 'JFK')
which is true in a current world W if there exists W1 accessible
through the meaning of add_flight(..), and reachable('LA','JFK') is
true in W1. Assume that reachable is the transitive closure of the
flight relation. The execution of the query is not very different
from Prolog execution. Thus the call <+flight(..)> will return a
new (world) database in which reachable(...) will be evaluated. If
this evaluation fails, backtracking will cause the inserted fact
flight(...) to be removed. Similarly, deletion on the database is
undone on backtracking.
If the query succeeds, it will return a new updated database and
display to the user, all the changes that have been made to the
current database. The user can then choose to commit these changes
and make them permanent, or reject them and leave the database
unchanged.
The language has a well-defined declarative semantics, and a syntax
that reflects this semantics. This makes it considerably better
than using assert and retract for database updates. As an example,
note that in my proposed extension, updates are statically scoped.
If p(X) is pure predicate or a state predicate, the database is
guaranteed to remain unchanged after it is executed. This can be
quite significant for compiler and database query optimization.
I did not allow updates to rule-defined predicates because I wanted
to guarantee that (not p(a)) was true after executing <-p(a)>.
However, I think that can extend the treatment if I use a weaker
semantics. I will mail copies of [1], [2] and [3] to anyone who
requests them. My apologies to Richard for forgetting to mail him a
copy of my paper.
-- sanjay
References:
[1] Sanjay Manchanda and David Scott Warren.
A Language for Database Updates.
In Jack Minker, editor, Foundations of Deductive Databases and
Logic Programming, Morgan-Kaufmann, Los Altos, CA, 1987.
[2] Sanjay Manchanda, Soumtira Sengupta, and David S. Warren.
Concurrent Updates in a Prolog Database System
Technical Report 86/28, Department of Computer Science,
SUNY at Stony Brook, Stony Brook, NY 11794,
December 1986, Revised Feb 1987.
[3] Sanjay Manchanda
A Dynamic Logic Programming Language for Relational Updates.
Phd Thesis, SUNY at Stony Brook, Stony Brook, NY 11794, December
1987.
------------------------------
Date: 17 Mar 88 03:49:59 GMT
From: munnari!vuwcomp!lindsay@uunet.uu.net (Lindsay Groves)
Subject: mine embarrassingly simple problem
I'll save Richard saying it -- this doesn't say much about the program, and
certainly doesn't explain why ancestral cuts are supposed to be necessary.
Could you describe the problem in a bit more detail and illustrate just
how the need for ansectral cuts arises? Perhaps a simplified version of the
problem could be used to illustrate the point. An example would certainly
help.
-- Lindsay Groves
------------------------------
Date: 23 Mar 88 01:16:54 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Subject: mine embarrassingly simple problem
In that case, why not just code it as
map(Function, Network) :-
generate(Function, Network),
test(Network),
!.
test(Network) :-
lemma(Network, StopCondition).
More generally, suppose that you had several cases:
test(Network) :-
lemma(Network, ~~~),
!(map(_,_)),
p(...).
...
test(Network) :-
lemma(Network, ~~~),
!(map(_,_)),
q(...).
Then you could recast this as
map(Function, Network) :-
generate(Function, Network),
test(Network, Continuation),
!,
finish(Continuation, ...).
finish(p, ...) :-
p(...).
...
finish(q, ...) :-
q(...).
test(Network, p) :-
lemma(Network, ~~~).
...
test(Network, q) :-
lemma(Network, ~~~).
The basic idea is to redesign your "test" code so that it breaks into
three pieces: before-the-cut, the ancestral cut, and after-the-cut,
and then unfold the call to it so that the cut is exposed in "map".
------------------------------
Date: 20 Mar 88 20:55:02 GMT
From: lagache@violet.Berkeley.EDU (Edouard Lagache)
Subject: My views on developing a PROLOG standard
To help get the creative juices flowing on those position papers,
I thought I would throw in my two cents worth on this proposed
standard.
While I am not really qualified to make much commentary on the
subject (So what? that has never stopped me before!), there are a
number of peripheral matters that I would like to see addressed.
The matter of greatest concern for me is the question of whose
standard will be the standard? The BSI group is a British standard;
Now I hear that the French are working on their own standard (the AFNOR
group). All this is fine and good except that in all likelihood the
resulting standards will have about as much similarity with each other
as the French and English (natural) languages do (never mind the fact
that neither standard will have have much to do with existing practice)
- This is progress!?!
Perhaps this is a wild fantasy on my part, but I would really
like to see ONE (1) standard. That standard should be agreed upon not
just by the British and the French, but by ALL the major users of
PROLOG which includes (at the very least) most of Europe, Japan, and
the U.S. It seems to me that someone should bug the ANSI standard
committee, NOT to come up with their own standard (Lord have mercy on
all those "C" and FORTRAN users once the new standards are in place),
but to take part in an international effort to come up with the before
mentioned 1 PROLOG standard.
Fantasies aside, I do have a few comments on the BSI standard. On
the specifics of the "grimoire", I can only steal a quote from the
venerable Michael Clancy: "Do the right thing". In this case, "Do the
right thing" means try to capture existing practice as much as possible
(see "lots of smoke" on exactly what existing practice means on the
FORTRAN SIG). I do believe that asking the question of how existing
code would run under the new standard is a valuable measure of the
success at capturing existing practice. Unless there is a *strong*
reason to change syntax, the new standard shouldn't depart from
existing practice. Thus, I have read Richard O'Keefe's comments on his
perceptions of the standard syntax with real concern. Until I see a
"reasonable" reply from the standards committee, I am inclined support
Richard O'Keefe's position on this matter.
At the end of last week there was some discussion of the standard
library. Here I have one suggestion, make the library big enough so
that people don't have to reinvent the wheel all the time. I took a
lot of heat for my imfamous PROLOG libraries, while the code quality
was perhaps inadequate, I believe that the concept was valuable. Even
in as rich a language as Franz LISP, I still found the need for 1600
lines of additional general purpose functions. So there is a lot of
room expansion in PROLOG.
I would like to suggest defining a separate set PROLOG libraries,
much in the same way the UNIX "C" library is (was?) defined
independantly of the language. In this area, I would strongly suggest
various levels of libraries. There should be some core set that would
be required for the standard language, then additional standards would
be defined for supplemental libraries. <*Fantasy mode on*> Ideally
the standards committee should provide source code for those
supplemental libraries in the core standard language (when possible),
so that anyone using any standard PROLOG implementation could use the
full set of libraries (if more slowly than if all the predicates were
builtin). <*Fantasy mode off*> In any case, Everybody knows that the
first thing PROLOG system implementors do is to embellish on the
standard core library, so wouldn't it be nice if the standard included
a few hundred predicates to keep those implementors busy upgrading
their product in a standard way (maybe I should have kept Fantasy mode
on?)
The last thing I would really like to see is some vast
improvement in the standard user interface tools. Even if not all
hardware can support it, I would like to see some standard way to
access windows, i/o devices (i.e. mice), and or forth. If one could
write complete applications in PROLOG that had portable "bells and
whistles", that would make PROLOG much more attractive for those trying
to make polished products for end users, since that would greatly reduce
porting problems (I know, Fantasy mode is still on!)
Still dreaming in California,
-- Edouard Lagache
------------------------------
Date: 23 Mar 88 01:09:49 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Subject: My views on developing a PROLOG standard (long but fun!)
Wrong. Roger Scowen of NPL get the thing started; since the NPL is in
England he naturally got the thing started as a BSI project. AFNOR are
not developing a rival standard; they have been collaborating with the
BSI group for a long time now, and the Formal Specification is French work.
(While many people will find it the most confusING part of the BSI material,
it is arguably the least confusED.) The whole thing has now become, I hear,
an ISO "work item", and the more recent BSI documents bear ISO reference
numbers.
> That standard should be agreed upon not
> just by the British and the French, but by ALL the major users of
> PROLOG which includes (at the very least) most of Europe, Japan, and
> the U.S.
Hear hear. And don't forget the South Pacific (home of NU Prolog and CLP)
or Israel (home of Wisdom Prolog).
> I took a
> lot of heat for my imfamous PROLOG libraries, while the code quality
> was perhaps inadequate, I believe that the concept was valuable.
Too right.
> The last thing I would really like to see is some vast
> improvement in the standard user interface tools. Even if not all
> hardware can support it, I would like to see some standard way to
> access windows, i/o devices (i.e. mice), and or forth.
I understand that agreement on the Common Lisp binding for X is at least
a year away. Plagiarism being the sincerest form of flattery, I suggest
that it might be an idea to wait for the Lisp people to do the work, and
then transliterate as much of it as possible. Or would a 'curses'
binding be of more immediate use? Either way, I don't see any need for
a standard way to access Forth; Postscript maybe, but not Forth (:-).
-----------------------------
Date: 21 Mar 88 09:26:04 GMT
From: nsc!taux01!shahaf@decwrl.dec.com (Shahaf Moshe)
Subject: mine embarrassingly simple problem
First I would like to make two comments:
* I am a NOVICE (in Prolog).
* I do not claim that in my application Ansectral Cut are a MUST. I wrote it on
a system were it was a feature and I used it. Since its not available in
Quintus Prolog, I asked for help.
About the application,
The program looks for best mapping of a Boolean function onto a set of logic
primitives such as
X * Y * Z maps to: 2inputAnd( 2inputAnd( X, Y) , Z)
or: 3inputAnd( X, Y, Z)
Since the search space is huge I used Ansectral Cut to abort
mapping once I get some "STOP CONDITIONS".
The program looks like:
map(Function,Network) :-
generate(Function,Network),
test(Network).
test(Network) :-
lemma(Network,StopCondition),
!(map). %this cut aborts the process.
I hesitate to post longer description on the net. If anyone would like to
get more elaborated data I will mail upon request.
------------------------------
Date: 19 Mar 88 03:04:08 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Subject: behavior of read/get0 at end_of_file
I thought you might be interested to know what the BSI committee say.
In document PS/236, "Draft minutes, Prolog Built-In Predicates meeting,
10 December 1987", we find
4 Design criterion
<name deleted> suggested: "Whenever possible, a predicate with
a side effect should always succeed and never instantiate
variables."
This of course rules get0/1 and read/1 out entirely. That may not be
what <name deleted> _meant_, but it _is_ what the minutes say he _said_.
As far as I can tell, the real intent is to rule out retract/1, which
is disliked because it unifies its argument with the thing you removed.
The minutes show that Paul Chung proposed naming the standard clause-
removing predicate delete/1 instead of retract/1. Good on yer, mate!
This should not be construed as endorsement of the name delete/1, but
as praise for Paul Chung's good standardisation manners.
------------------------------
Date: 22 Mar 88 15:56:23 GMT
From: mcvax!unido!ecrcvax!micha@uunet.uu.net (Micha Meier)
Subject: behavior of read/get0 at end_of_file
This is true, we have to distinguish various uses
of get0/1. The above example is indeed easier
written when get0/1 fails at the eof, because the is_endfile/1
test is not needed. However, most often one wants to do more
with the character rather than just test the eof, and only
then the differences are meaningful.
By the way, get0/1 does *not* exist in BSI, it uses get_char/1 instead,
and its argument is a character, i.e. a string of length 1.
This means that the type 'character' is inferred from
the type 'string' (and not the other way round like in C).
Does anybody out there know what advantages this can bring?
It is independent on the character <-> integer encoding,
but this only because explicit conversion predicates have
to be called all the time.
In his tutorial to the SLP '87 Richard has taken another
representation of a finite automaton which is more
appropriate:
s1 :-
get0(Char),
s1(Char).
s1(0'a) :-
s2.
s1(0'b) :-
s1.
s1(-1) :-
accept.
The difference is, that if one wants to perform some action
in some states, this must be done *before* reading the next character,
i.e. just at the beginning of s1/0. Such representation can
be more easily converted to the BSI's variant of get:
s1 :-
% do the corresponding action
( get0(Char) -> s1(Char)
;
accept
).
s1(0'a) :-
s2.
s1(0'b) :-
s1.
Note that the eof arc has to be merged into s1/0 in this way
since if we'd write it like
s1 :-
s1_action,
get0(Char),
!,
s1(Char).
s1 :-
accept.
then after an eof we would backtrack over s1_action and undo
what we've done.
I must say, none of the two seems to me satisfactory. Richard's
version is not portable due to the -1 as eof character. We can
improve this into
s1(X) :-
eof(X),
accept.
s1(0'a) :-
s2.
s1(0'b) :-
s1.
and hope that the compiler will unfold the eof/1 inside the
indexing mechanism, otherwise we have choice points even
if the code is deterministic.
The BSI version is much more arguable, though. Having to
wrap a disjunction (and a choice point) around the get0/1 call
suggests that for this application the BSI choice is not
the appropriate one. It is interesting to note, however, that
it could work even with nondeterministic automata, where the BSI's
failure was (I thought) more likely to cause problems.
For a Prolog system it is better to have get0/1 return
some *portable* eof (e.g the atom end_of_file, for get0/1
there can be no confusion with source items) instead of
some integer.
This, however, just shifts the problem up to read/1:
BSI objects that if it returns e.g. the atom end_of_file
then any occurrence of this atom in the source file
could not be distinguished from a real end of file.
In this case, a remedy would be the introduction of
a term with a local scope (e.g. valid
only in the module where read/1 and eof/1 are defined) and
using eof/1 instead of unifying the argument of read/1 with
the end_of_file term. Hence read/1 would return this term
on encountering the file end and eof/1 would check whether
its argument is this term.
--Micha
------------------------------
Date: 20 Mar 88 20:51:12 GMT
From: lagache@violet.Berkeley.EDU (Edouard Lagache)
Subject: Seeking opinions on BSI PROLOG standard proposal.
I spent a few hours carefully collecting all the
comments on the proposed BSI PROLOG standard that have been
posted to the PROLOG SIG. The result was a 160Kb file! The
reason for this exercise in tedium was my desire to write an
article on the pros and cons on this standard for the next
issue of the PROLOG Forum newsletter. However, for obvious
reasons, I am not particularly anxious to try to comb through
all them bytes of complex argumentation, and I am not
optimistic that I could do any of the participants justice.
Thus, I would like ask those persons who expressed some
substantial position on the new PROLOG standard, if they
might be interested in submitting to the PROLOG Forum
something equivalent to a short (1-3 page) position paper on
the standard.
Because we are such a new group, our editorial policies
are still in the process of coalescing, but at the moment I
would think that a very informal sort of piece of the sort
that you might post to the net would be very acceptable.
Should you have any interest and/or questions please
direct them to me, and I will do my best to answer them or if
necessary to rely them to our newsletter editor.
I am looking forward to a lot of interesting commentary!
-- Edouard Lagache
P.S. A minor detail, but anyone wishing to submit a text can simply
e-mail it to this account. If prefered, one could send an
PC or Mac compatible disk with the text in "flat ASCII" format to:
The PROLOG Forum
P.O. Box 3826
Redwood City, CA, 94064, USA.
------------------------------
Date: 21 Mar 88 16:40:44 GMT
From: eagle!icdoc!doc.ic.ac.uk!cdsm@ucbvax.Berkeley.EDU (Chris Moss)
Subject: BSI
Forwarded for Roger Scowen -- KRG0@gm.rl.ac.uk
RESPONSE TO COMMENTS FROM RICHARD O'KEEFE ON PROLOG STANDARDIZATION
GENERAL RESPONSE
Richard O'Keefe started by saying that he would respond to the
mailing from Chris Moss. In fact many comments refer
to a document (Prolog syntax, Draft 4.1) that
most news readers (and members of the ISO and BSI panels) will
not have seen.
This seems somewhat unfair on readers who will be unable to judge
whether draft, criticism, or rebuttal is justified.
First some general comments. The objective is to define an
International Standard for the programming language Prolog.
This means that standard conforming programs will run correctly
on standard conforming processors, neither more nor less.
It will not limit implementers from introducing new features and
facilities into their Prolog compilers.
Neither will it mean programmers cannot use such extensions; only
that if they do, their programs will not conform to the standard.
But a standard will permit people and companies to write applications
and libraries that will run on any conforming implementation
and thus give them a framework in which to work. In particular, such users
and their customers will not be restricted to a single implementation.
A standard will also give teachers, authors and students a common core
of useful Prolog.
Once a feature has been included in a standard, it is almost
impossible to remove. The committee remembers that Fortran has been
burdened with arithmetic if statements and computed goto statements.
In Prolog we hope to avoid such legacies if possible.
So some features of Edinburgh Prolog will not be in the standard
because although they fulfilled a need at one time, they are
not a sensible longterm solution.
Now some replies to specific criticism.
DIVERSITY OF EXISTING PROLOG SYSTEMS
Chris Moss has produced tests that give
different results on every system tested so far. Perhaps there
is rather more diversity than Richard O'Keefe realizes.
One objective has been to define a syntax where many existing
systems would not generally disagree on the meaning of
standard-conforming programs.
PROLOG CONTROL STRUCTURES AS SYNTAX
> (3) The attempt to describe Prolog control structures as *syntax*
> is fundamentally misdirected.
This is a matter of opinion. One reason for regarding Prolog control
structures as *syntax* is so that a person or program reading
a Prolog program can always recognize its overall structure.
NOTICE OF MEETINGS
Meetings are planned and advertised several months in advance,
for example, the following meetings are already planned:
BSI, London on Thursdays 2nd June, 1st Sept, 1st December 1988.
Any extra meetings to discuss the syntax will be on the previous
day (i.e. 1st June, etc); any meetings to discuss built-in predicates
will be a week later, i.e. 9th June, etc.
Everyone who wishes to attend is welcome. I admit that pressure of
work means that some papers are sent only a week before the meeting.
This is ample for British members of a British panel, but not for
Californian members.
But other papers will have been sent four or five weeks earlier.
All comments, whether they are received before or after a meeting,
are read and considered.
',' and '&' AS OPERATORS
It is not intended that it will be possible to declare ',' and '&'
as operators.
A MISTAKE IN COMMENTS
/** By L22, this is not a legal comment **/
Thank you. This will be a valid comment in standard Prolog despite
the error in this draft.
QUOTE OPERATORS USED AS OPERANDS
Richard O'Keefe realizes that the above example is intended to be
syntactically incorrect in the standard. When operators are
used as operands, there many problems of possible ambiguity.
A cure is still under discussion, but some problems are
avoided by the rule that "An operator used as an operand must be
bracketted".
AN INFIX CONS OPERATOR
We are still considering the problems posed by the multiple uses of '.',
i.e. as a decimal point, as an infix cons operator, and as a clause
terminator. At the same time we desire to make layout characters
unimportant in determining the meaning of a program.
Several possibilities have been suggested and are under consideration.
NEGATION
It is intended that Standard Prolog will not contain 'not' or '\+'.
Standard Prolog will not require systems to implement true
logical negation and it would be misleading to include an
operator or predicate that implies that they have done so.
Instead the way is left open for processors to implement a version
of 'not' as an extension and still remain standard conforming.
Standard Prolog will contain a built-in predicate
that implements 'negation by failure', i.e.
fail_if(G) :- call(G), !, fail.
fail_if(_).
A PARSER AS STANDARD
A program that resolves ambiguity implicitly is not acceptable as
defining a standard; there must be further definition.
One reason is that a program specifies too much. Some features need to
remain 'implementation dependent' because we must not specify
them, for example: the accuracy and largest values of floating point
numbers, or the integer value corresponding to a character.
Another reason is that it is harder to understand and find errors.
DISCLAIMER AND CONCLUSION
Never rely on working papers and draft standards. They are subject to
changes and review. All documents and working papers, however
confidently expressed, are also subject to review. There will be no
standard until the member bodies of ISO have approved it.
The next working drafts will incorporate changes arising from further
consideration and the comments received (including those from
Richard O'Keefe).
Many countries, but not at present USA, have national Prolog panels
coordinating their views on the emerging standard. I encourage all
Prolog implementers and users to participate in this effort in order that
the eventual standard is one that preserves the best of the past
and also provides development paths for the future.
-- Roger Scowen
-------------------------------
Date: 23 Mar 88 05:11:45 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Subject: BSI syntax
Message-Id: <797@cresswell.quintus.UUCP>
References: <234@gould.doc.ic.ac.uk>
Sender: prolog-request@score.stanford.edu
To: prolog@score.stanford.edu
My postings were in fact a response to Chris Moss's mailing. They were
not confined to the content of that mailing, true. It seemed to me that
Chris Moss's mailing implied that the BSI syntax was in a satisfactory
state, and that it wasn't as difference from the de facto standard as
people feared. I set out to show that neither of those statements is
true, and I believe that I succeeded.
Many comments did refer to a document that most news readers won't have
seen. But then, most news readers won't have seen ***ANY*** of the BSI
documents. Am I then to say nothing? As for fairness to readers,
(a) I was quoting from the very latest document I had.
Surely it would be more unfair to quote from something I believed
to have been superseded?
(b) The "February 88" and "Feb 88" documents arrived in my mailbox here
in the same week. I had no way of telling who had or had not
received the document I was quoting. All I knew was that this was
the latest document available, sent to me by the author.
(c) In order to permit readers to judge for themselves whether my
criticisms were justified, I quoted extensively from the document.
I did not ask anyone to take it on faith that this or that was the
case: where the grimoire appeared to say something particularly
silly I exhibited the rules responsible. This is unfair?
> First some general comments. The objective is to define an
> International Standard for the programming language Prolog.
> This means that standard conforming programs will run correctly
> on standard conforming processors, neither more nor less.
> It will not limit implementers from introducing new features and
> facilities into their Prolog compilers.
>
> Neither will it mean programmers cannot use such extensions; only
> that if they do, their programs will not conform to the standard.
>
This is a little misleading. The general rule in other languages is
that implementors can add extensions, provided that such extensions
are either illegal or undefined in the standard. Thus a Pascal compiler
can provide alphabetic labels as an extension. But an implementor
should not provide an extension which alters the meaning of a program
which the standard would have ruled legal.
Let's apply this to the case of :- read(_). directives in a file which
is being consulted or compiled. Specifically, let's consider a file
which looks like
:- read(_).
p(a).
and has nothing else in it. Does this define p, or does it not? The
BSI grammar, in all versions, provides the syntax of entire files:
according to the grimoire this MUST mean exactly one directive followed
by exactly one clause. Since this is a defined and legal file, it would
be most improper for an implementor to give it any other meaning.
Therefore, reading out of a file being compiled or consulted is NOT
a permitted extension. (This wouldn't bother Quintus, but it is legal
in some other Prologs.)
Let's apply this to another case: functor/3. It has always been the
case in DEC-10 Prolog that functor(1, 1, 0). In at least one draft of
the BSI built-in predicates document, this has been required to raise
an error. (BSI Prolog includes an error handling facility; needless
to say it doesn't look like IF/Prolog's or M-Prolog's or ...) So a
BSI conforming program is entitled to rely on this error being raised,
and an implementor may NOT provide DEC-10 compatibility.
The ANSI C committee have found it necessary to explicitly indicate
which identifiers may be used by implementors. (The list includes
all identifiers starting with "_" or "str" and there are others I
can't remember right at the moment.) Why is this? Because the
programmer needs a guarantee that the identifiers he has chosen for
his code won't be in conflict with an implementation. For example,
(not)/1 is not defined in the BSI stuff, so Scowen says that an
implementation is free to define it. But if the implementation is
free to do so, then the programmer ISN'T. Since setof/3 is not in
the BSI Prolog language, a program which defines
setof(List, Set) :-
setof(List, [], Set).
setof([], Set, Set).
setof([Head|Tail], Set0, Set) :-
( member(Head, Set0) ->
setof(Tail, Set0, Set)
; /* not member(Head, Set0) */
setof(Tail, [Head|Set0], Set)
).
is a standard-conforming program. But a Prolog system which is exactly
BSI except for providing setof/3 as an extension is a conforming processor.
Will such a conforming program run correctly on such a conforming
processor? You must be joking. So, taken in their ordinary sense,
the claim that "standard conforming programs will run correctly on
standard conforming processors", while true of some standards, is NOT
true of the BSI work, unless "standard conforming processors" is
construed very strictly as meaning "providing NO additional built-in
predicates".
You will recall that Fortran 77 provides the EXTERNAL and INTRINSIC
statements precisely to cope with this problem, and that ANSI C
provides the reserved-to-implementors list and #undef precisely to
cope with this problem. BSI Prolog does have some reserved words,
but is ludicrously far from providing a solution to this problem.
> So some features of Edinburgh Prolog will not be in the standard
> because although they fulfilled a need at one time, they are
> not a sensible longterm solution.
Let's be realistic. There are languages on the horizon which are much
better approximations to logic programming than Prolog. (NU Prolog has
been around for a while.) There are lots of software engineering needs
which old Prolog completely failed to address, such as modules. (Last
I heard, the consensus of the BSI Modules subcommittee was that they
would probably never agree.) I think we ought to regard Prolog as a
stopgap; and that the goal of the standard should be to protect EXISTING
investments in Prolog. Frankly, advocates of BSI Prolog, with its
use of user-supplied atoms as stream names, are in no position to talk
about sensible solutions.
************************************************************************
** It would be most interesting to have an explicit list of the features
** of Edinburgh Prolog which fulfilled a need at one time and are now
** disliked by the committee, and a description of their replacements.
************************************************************************
> > (4) The basic structure of the BSI approach to syntax has been
> > to cut the Gordian Goose. That is, instead of regarding the
> > (actually rather low) diversity of Prolog syntax as an
> > opportunity to be solved by making the language more powerful
> > (e.g. having a table-driven tokeniser), it has been treated as
> > a problem to be solved by inventing a new, more restricted,
> > language.
>
> Well, yes and no. Chris Moss has produced tests that give
> different results on every system tested so far. Perhaps there
> is rather more diversity than Richard O'Keefe realizes.
> One objective has been to define a syntax where many existing
> systems would not generally disagree on the meaning of
> standard-conforming programs.
The amount of diversity one perceives depends on which "Prolog" systems
one decides to include in one's sample. My sample includes only systems
whose implementors _tried_ to be Edinburgh (or at least Clocksin &
Mellish) compatible. For example, AAIS Prolog is openly and frankly
not an Edinburgh-compatible system. We may (and should) look to it for
ideas, but we should not include it in a sample of "Edinburgh compatible"
Prologs. BIM Prolog has its own unique syntax; while we should perhaps
include the '-c' syntax of BIM Prolog in the sample, we should not
include BIM Prolog's native syntax. If we go by numbers, then Turbo
Prolog should determine the syntax of standard Prolog. If not by numbers,
by what? Simple justice suggests that the Prologs to look at are the
Prologs whose authors TRIED to be compatible with one another. Prudence
suggests the same sample.
But even if the diversity among the Prologs whose authors didn't suffer
from NIH-itis is much greater than I believe, that doesn't answer my
point. What I said was that the diversity should be regarded "as an
opportunity to be solved by making the language more powerful (e.g.
having a table-driven tokeniser)". [As an aside, this is no more than
Lisp and PopLog already have.] It turns out that it is quite easy to
write a tokeniser which can handle all of
ALS Prolog
Arity Prolog
BIM Prolog native syntax
C Prolog
DEC-10 Prolog
PopLog (nested comments)
Quintus Prolog
Stony Brook Prolog
and can almost handle ADA [ADA is no longer a trademark], simply by fiddling
with a table. AAIS took exactly this approach (though their tokeniser is
not as flexible as mine). I found it necessary to support several kinds
of quotes in my tokeniser:
ATMQT - the quoted thing is an atom (')
STRQT - the quoted thing is a string ($)
LISQT - the quoted thing is a list (")
CHRQT - the quoted thing is a character (`)
Suppose the standard were to adopt this approach, then they could rule,
if they wished, that the standard assignment was "->STRQT, with nothing
being assigned LISQT. That needn't prevent me reading my existing code:
I'd be able to change the table while reading my old files.
[The best approach seems to be to associate a read table with a stream;
naturally this is the approach PopLog takes.]
What I have in mind here is that a file would start with a directive
such as
:- use_syntax(dec10).
or :- use_syntax(standard).
or :- use_syntax(als).
Especially if the tokeniser were made available to user code (as it is
in the DEC-10 Prolog library, or built-in in NU Prolog), the result would
be a much more powerful language at very little cost to the implementor.
And conversion from old dialects to the BSI dialect would be enormously
simplified.
Do we need to come up with a "best possible" tokeniser for the standard?
Of course not.
Again, what are we to do about syntactic variations, such as the
treatment of operators? My answer, in 1984, was that the standard
should not specify read/1 and write/1, but should specify
standard_read/1
standard_write/1
and should allow users to redefine read/1 and write/1, but require
that the initial definitions be the standard one. consult and compile
should use read/1, not standard_read/1, so that someone who wanted to
read M-Prolog files into standard Prolog could do so by suitably
defining read/1.
Now, if you are a self-appointed standards committee member determined
to impose your vision of what is a "sensible longterm solution" on
every Prolog user whether they like it or not, this sort of approach
won't seem all that attractive. But if, like me, you think that the
people who matter in all this are the people who have paid money to
USE Prolog, and if, like me, you think that the fact that M-Prolog
is appalling is no reason to make life any harder for people with a
lot of data in M-Prolog format than we have to, you'll think that
letting people do
read(Term) :- magyar_read(Term).
is obviously the way to go. (It doesn't much matter how you install
your own code in the hook, the important thing is that there should be
a read-hook where you can install your own reader to be used by compile
and consult.)
> PROLOG CONTROL STRUCTURES AS SYNTAX
> > (3) The attempt to describe Prolog control structures as *syntax*
> > is fundamentally misdirected.
> This is a matter of opinion. One reason for regarding Prolog control
> structures as *syntax* is so that a person or program reading
> a Prolog program can always recognize its overall structure.
It is not a matter of opinion. Either I am right about this, or I am
wrong. There is a very important reason for my belief: Prolog is
simply not the sort of language for which this kind of thing can WORK.
Consider the difference between
foo(X, P, Q, L) :- bag(X, (P & Q), L).
↑↑↑↑↑↑↑
and
de_morgan((P & Q), (R | S)) :- de_morgan(P, R), de_morgan(Q, S).
↑↑↑↑↑↑↑
The first is code, and the treatment of it in the grimoire is appropriate.
(That is, it will be mapped to whatever "(and ?P ?Q)" would have been
mapped to in the BSI Lisp-like syntax.)
But the second is data, and the treatment of it in the grimoire is
NOT appropriate. It will be mapped to whatever "(and ?P ?Q)" would
have been mapped to in the BSI Lisp-like syntax, but it SHOULD be
mapped to whatever "[& ?P ?Q]" would be mapped to.
If we consider a slightly different example:
baz(X, P, L) :- bag(X, P, L).
↑
and
de_morgan(not(P), R) :- de_morgan(P, R).
↑
we find the opposite problem: the second is data and will be mapped to
whatever "?P" will be mapped to in the BSI Lisp-like syntax, but the
first is code, and should be mapped to whatever "(and ?P)" would be
mapped to, BUT IT WON'T BE.
The trouble is that the grimoire tries to guess whether something is
code or data by looking at its form, but that's the wrong place to
look: the place to look is the predicate being called. And the
trouble is that we can't build that information into the grammar,
because the programmer can define new predicates with code-like arguments.
Let me stress this:
the whole basis of the build-it-all-into-the-syntax approach
is the assumption that code is code and data are data and
never the twain shall meet.
This is true of Pascal. It is true of Fortran. It is almost true of C.
But it is utterly false of Lisp and Prolog. A grammar of this type does
not make SENSE for Prolog any more than it makes sense for Lisp.
I hereby wager US$100, payable once to Chris Moss, that if the next draft
of the grimoire attempts to maintain this rigid distinction between code
and data, I will be able to find inconsistencies like the ones above in
it. I don't think it's Chris Moss's fault: if anyone can find a way of
working around this basic mistake (not HIS mistake, by the way, this is
the kind of grammar the BSI committee have always wanted), I'm sure that
Chris Moss could. I make my wager *despite* my belief in Chris Moss's
competence, because I believe that it is _impossible_ for this approach
to work. (If I do not receive said draft by the end of this year, the
wager will expire.)
> ',' and '&' AS OPERATORS
> > Oddly enough, if one takes the grimoire literally, the user CAN
> > declare ',' and '&' as operators, and can use them in that form.
> > However, ',' and '&' cannot possibly have the same precedence as
> > "," or "&" in BSI Prolog, and it seems clear that (A ',' B) and
> > (A '&' B) must be different terms.
>
> It is not intended that it will be possible to declare ',' and '&'
> as operators.
>
There is nothing in the grimoire to say so, and it is a very odd restriction.
Intentions are beside the point: all that matters is what the documents
actually say. It *is* the intention that it should be possible to write
','(A,B) as a term, and it remains the case that ','(A,B) and '&'(A,B)
must be different terms, and if we take the grimoire literally, neither of
them can be the same as (A,B) or (A&B).
[Yes, I know about (P|Q) and (P;Q) in Dec-10 Prolog. I have always thought
and said that this was a mistake, and I think it is one of the very few
areas where a difference between the standard and existing practice might
be justifiable.
]
> QUOTE OPERATORS USED AS OPERANDS
> > compare(R, X, Y) :-
> > ( X @> Y -> R = >
> > ; X @< Y -> R = <
> > ; R = =
> > ).
>
> Richard O'Keefe realizes that the above example is intended to be
> syntactically incorrect in the standard. When operators are
> used as operands, there many problems of possible ambiguity.
> A cure is still under discussion, but some problems are
> avoided by the rule that "An operator used as an operand must be
> bracketted".
>
Well, it would be more accurate to say that I COMPLAIN that it is
intended to be syntactically correct in the standard.
There isn't any problem of possible ambiguity here whatsoever.
) :- ( :- must be infix
X @> Y @> must be infix
Y -> R -> must be infix
R = > = must be infix or suffix, has no suffix reading
= > ; > must be atom or prefix, has no prefix reading
> ; X ; must be infix
and so on
Now if = and > _both_ had a suffix reading, (R = >) would be ambiguous.
Since neither of them has, there is no ambiguity here at all.
The elimination of ambiguity is not a very good argument for breaking
existing UNAMBIGUOUS code!
> NEGATION
> > not Goal :- % "not" is not a built-in operator
> > ( ground(Goal) -> \+ Goal % neither is "\+".
> > ; signal_error(instantiation_fault(Goal,0))
> > ).
> It is intended that Standard Prolog will not contain 'not' or '\+'.
> Standard Prolog will not require systems to implement true
> logical negation and it would be misleading to include an
> operator or predicate that implies that they have done so.
> Instead the way is left open for processors to implement a version
> of 'not' as an extension and still remain standard conforming.
> Standard Prolog will contain a built-in predicate
> that implements 'negation by failure', i.e.
> fail_if(G) :- call(G), !, fail.
> fail_if(_).
My main point here was a semantic one. Most other control structures
are defined in the grammar. It seems odd that
( G -> fail ; true ) should be in the grammar, but that
fail_if(G) which is identical in effect, should not.
Because one of these forms is in the grammar and the other isn't, they
have different properties. For example,
( 1 -> fail ; true ) is syntactically illegal, but
fail_if(1) is syntactically legal.
There are other differences as well.
If BSI Prolog contains fail_if/1, then it WILL contain '\+', but with
a different name. Why not use an existing name for an existing
operation? Looks to me like nonhicinventusitis. \+ is a crossed-out
|-, meaning, obviously enough, "not provable".
> A program that resolves ambiguity implicitly is not acceptable as
> defining a standard; there must be further definition.
> One reason is that a program specifies too much. Some features need to
> remain 'implementation dependent' because we must not specify
> them, for example: the accuracy and largest values of floating point
> numbers, or the integer value corresponding to a character.
>
> Another reason is that it is harder to understand and find errors.
It is harder to understand and find errors in a program you can run
than in a never-used-anywhere-else formalism? Judging by the results,
this is the opposite of the truth.
What is the difference between the public-domain DEC-10 Prolog parser
and the BSI grimoire? Both are programs, in a formalism based on logic.
Neither is more explicit or less explicit than the other, and both are
of similar size. So what is the difference? The difference is that
the public-domain DEC-10 Prolog parser CAN be run, HAS been run, and
has had most of the mistakes knocked out of it by actual experience.
The BSI grimoire is in a new formalism, the definition of which is
provided in ***NO*** BSI document (so that I had to keep guessing what
things meant), and each of the three drafts I have seen was riddled
with errors from end to end. I haven't told you about all the problems
I found; there are nearly as many problems as rules!
The BSI Prolog group HAVE specified the integer value corresponding to
a character: they require the ISO 8859 character set. GREAT!
The DEC-10 public-domain ***parser*** does NOT specify the integer
value corresponding to a character (that's the tokeniser's job).
{The old tokeniser did have ASCII codes built in, but the current
version of the tokeniser uses 0'x syntax for the appropriate
constants to avoid that problem.}
If the BSI committee are so concerned to avoid character code problems,
how come they haven't got anything like 0'x or `x` (in a standard which
doesn't have to cope with existing code that uses ` as an atom, `x` is
a good notation for character code constants)?
The public-domain tokeniser doesn't specify anything more about floating
point numbers than what they look like, it relies on being provided with
a number_chars/2 predicate (which we want ANYWAY) do to the actual
conversion.
Note that the BSI grimoire says NOTHING about what happens if you write
a constant which exceeds the capacity of your implementation. Is the
program
p(1.2e3456).
a BSI-conforming program or not? Well, syntactically it is, but the
lexical rules say nothing about what it MEANS. For all that the
grimoire or any other BSI document I can recall says to the contrary,
a Prolog implementation which reads this as
p(0.0).
is conforming. This kind of thing is a real portability problem; it
exists with respect to integers too. Is 1000000000000000000 a legal
Prolog term? According to the grimoire, yes. What does it mean?
The grimoire doesn't say.
> DISCLAIMER AND CONCLUSION
> Never rely on working papers and draft standards. They are subject to
> changes and review. All documents and working papers, however
> confidently expressed, are also subject to review. There will be no
> standard until the member bodies of ISO have approved it.
But what ELSE is there to comment on?
> Many countries, but not at present USA, have national Prolog panels
> coordinating their views on the emerging standard. I encourage all
> Prolog implementers and users to participate in this effort in order that
> the eventual standard is one that preserves the best of the past
> and also provides development paths for the future.
>
> Roger Scowen, 11 March 1988
Sorry, but it's too late. Prolog implementors and users should have been
invited to contribute before the committee went on a four-year binge of
inventing their own language. I explicitly suggested some years ago that
the people at WISDOM should be invited to participate, and was told that
that was out of the question. I have put a lot of effort into writing
responses to the BSI stuff, and for all the feedback I've had I might as
well have been shouting into a vacuum. The BSI committee having been
resolute in their contempt for existing Prolog users (I have repeatedly
urged that they should explicitly adopt a principle of not breaking
existing code without strong necessity, as the ANSI C committee did, and
the last I heard was that they had explicitly rejected any such idea),
I cannot regard "preserves the best of the past" as anything but a sick
joke.
Look, if you want to preserve the best of the past, why have you
renamed findall/3 to bag/3? Why have you adopted ESI Prolog-2's
streams rather than Arity/Prolog's streams, despite having been
told about the problems? Could it be something to do with the
fact that the author of that part of the standard worked for ESI,
not for Arity? Why have you dropped nl/0 from the standard? Why
is there no notation for character constants such as PopLog provides?
Why is the error handling facility all new, rather than resembling
either IF/Prolog or M-Prolog?
I have tried, I really have tried, to arouse interest in the BSI work
here in the US. Do you know what has got in the way? As soon as I
show people any of the BSI documents (take the 'standardisation issues'
documents as an example) they say "what a pack of turkeys" and assure
me that there is nothing to worry about. I remain desperately worried
that there will be a BSI/ISO Prolog standard, and that it will be as
bad as the current drafts, and that it will do a great deal of damage.
What *really* worries me is that the people on the BSI committee don't
seem to realise how bad it is.
------------------------------
End of PROLOG Digest
********************
∂15-Jul-88 2120 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #46
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Jul 88 21:20:39 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA18687; Wed, 13 Jul 88 10:10:23 PDT
Date: Wed, 13 Jul 88 10:10:23 PDT
From: Chuck Restivo <restivo@polya.Stanford.EDU>
Message-Id: <8807131710.AA18687@polya.Stanford.EDU>
To: restivo@polya.Stanford.EDU
Subject: PROLOG DIGEST V6 #46
Date: Thu, 14 July 1988 02:53-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@POLYA.STANFORD.EDU>
Reply-to: PROLOG@POLYA.STANFORD.EDU>
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #46
To: PROLOG@POLYA.STANFORD.EDU
PROLOG Digest Thursday, 14 July 1988 Volume 6 : Issue 46
Today's Topics:
Implementation - Footnote & Call/1
-----------------------------------------------------------------------------------------------------------
Date: Tue, 5 Jul 88 12:22:36 EST
From: pereira
Subject: Footnote
In Digest V6 #26, Richard O'Keefe says
> However, there is an encapsulation which works nicely, due I think to
> Stuart Shieber, which Fernando Pereira told me about.
I did describe the idea to Richard, but I believe I attributed it to
its proper originator, Mark Johnson, formerly from Stanford and
currently at MIT.
-- Fernando Pereira
------------------------------
Date: Sun, 10 Jul 88 14:37:45 EST
From: pereira
Subject: Call/1 and goal processing
uicsrd.csrd.uiuc.edu!sehr@uxc.cso.uiuc.edu (David ?) writes
> It seems that if one allows the interpretation
> of dynamically constructed goals (i.e. those constructed via functor/3,
> arg/3, and univ (=..)), then one must cope with the possibility of
> variable dereferencing during the selection of a goal to process. Does
> anyone out there know how it is done in other interpreters (C-Prolog,
> SB-Prolog, etc.)?
In C-Prolog, that's exactly what happens. In a structure-sharing
system, a goal (or any other compound term) is specified by a
*molecule*, which is a pair consisting of a pointer to a *skeleton*
specifying the input form of the goal (compound term) and of a pointer
to an *environment* specifying the values of the goal's (term's)
variables (see David H. D. Warren's dissertation for details).
C-Prolog uses David Warren's two-stack storage scheme, in which
variables are classified as either local (go away on determinate exit)
or global (survive until backtracking). Ignoring the questions of mode
declarations (which don't exist in C-Prolog), of temporary variables
(which do, but don't make things that different) and last-call
optimization (which C-Prolog doesn't have) variables that occur only
as immediate arguments of a clause-head or goal are local, others
global.
When a *lexical* goal (one whose predicate symbol is defined at
program read-in time) is called, three values are required to get at
the goal: a pointer G to the source form of the goal (the goal's
skeleton), a pointer PL to the local environment for the clause
activation containing the goal, and a pointer PG to the corresponding
global environment (G, PL and PG are not the historically used names
for these pointers, but I can't remember those and I don't have the
appropriate reference material with me).
*Dynamic* goals in C-Prolog occur only through the agency of a
meta-call, either explicitly through a call/1 goal in the source or
implicitly through a variable goal in the source, which I think (I
don't have the C-Prolog sources handy and I haven't looked at them for
4 years) is translated into the explicit form when the clause
containing it is stored. In any case, the main point to observe is
that when call/1 is executed its argument should either be a constant
(trivial case) or a compound term. Assuming the meta-call is call(X),
X is first dereferenced. If its value is neither an atom or a
molecule, an instantiation error is signaled. In the atom case, G
points to the atom, PL to the parent clause's local environment and PG
to the parent clause's global environment. PL and PG won't be needed
for unifying the goal against clause heads, but PL still needs to be
saved for deep backtracking purposes. If X is bound to a molecule, G
is set to the molecule's skeleton, PL to the parent's local
environment and PG to the molecule's environment pointer. PL won't be
needed to get at the goal's variables, but is still needed for deep
backtracking purposes.
As for SB-Prolog, things are very different. I don't know the
internals of that system in detail, but I know it is a WAM-based
structure-copying system rather than a structure-sharing one. This
means that the value of X in call(X) will be an explicitly represented
term in the structure (heap) stack. A single pointer is thus needed to
represent the goal, but additional manoevers will be required to set
up the call as required by the WAM. I haven't studied how this is done
in detail.
-- Fernando Pereira
-------------------------------
End of PROLOG Digest
∂15-Jul-88 2143 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #42
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Jul 88 21:43:30 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA12277; Sun, 10 Jul 88 04:57:46 PDT
Date: Sun, 10 Jul 88 04:57:46 PDT
From: Chuck Restivo <restivo@polya.Stanford.EDU>
Message-Id: <8807101157.AA12277@polya.Stanford.EDU>
To: restivo@polya.Stanford.EDU
Subject: PROLOG DIGEST V6 #42
Date: Sunday, 10 July 1988 02:53-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@POLYA.STANFORD.EDU>
Reply-to: PROLOG@POLYA.STANFORD.EDU>
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #42
To: PROLOG@POLYA.STANFORD.EDU
PROLOG Digest Sunday, 10 July 1988 Volume 6 : Issue 42
Today's Topics:
Query - Call/1,
Implementation - KR,
LP Library - Book Review
-----------------------------------------------------------------------------------------------------------------------------
Date: 7 Jun 88 02:31:00 GMT
From: uicsrd.csrd.uiuc.edu!sehr@uxc.cso.uiuc.edu
Subject: Call/1 and goal processing
I am in the process of writing an Or-parallel interpreter for Prolog,
and have run across a difficulty. The question I wonder about is how
other interpreters that use a structure-shared representation go about
implementing call/1 in an efficient manner without unduly penalizing
ordinary goal processing. It seems that if one allows the interpretation
of dynamically constructed goals (i.e. those constructed via functor/3,
arg/3, and univ (=..)), then one must cope with the possibility of
variable dereferencing during the selection of a goal to process. Does
anyone out there know how it is done in other interpreters (C-Prolog,
SB-Prolog, etc.)?
-- David
------------------------------
Date: 15 Jun 88 19:41:11 GMT
From: quintus!ok@unix.sri.com
Subject: Knowledge representation and Prolog
This is a forwarded message.
In the future, I suggest that instead of sending things to me for
forwarding, people should send mail to the Prolog Digest at
Prolog@Polya.Stanford.EDU
FORWARDED MESSAGE:
Does anyone know of any KRL written in Prolog besides APES? Has anyone any
comments on attempts to mimic KEE or ART type systems in Prolog?
Jerry Harper: Merrion Gates Software, Rosemount Court, Booterstown Avenue,
: Co Dublin, IRELAND
jharper@euroies.uucp
------------------------------
Date: 16 Jun 88 18:13:38 GMT
From: antares!finin@burdvax.prc.unisys.com (Tim Finin)
Subject: Knowledge representation and Prolog
We here at the Unisys Paoli Research Center have been using KNET, a
Knowledge Represention system implemented in Prolog, on a number of AI
projects since about 1982. Attached is a brief description of KNET.
More details can be found in an article which will appear in a
forthcoming issue of the Journal of Logic Programming. Tim
KNET is a frame-based knowledge representation system developed at the
Unisys Paoli Research Center to support the acquisition and
maintenance of large, real-world knowledge bases. The KNET system is
currently being used in a rule-based diagnosis and maintenance system
(KSTAMP), in a model-driven configuration expert system (BEACON) and
in our natural language processing system (PUNDIT).
The KNET representation language is similar to KL-ONE in that it is
based on a formal semantic model which defines the meaning of objects
in its knowledge bases. Objects in the knowledge base are called
concepts, each of which has a unique name. A KNET knowledge structure
consists of a number of concepts organized into two distinct data
structures, called hierarchies. Each hierarchy has its own structure,
but the two are related in a complex manner.
The first hierarchy is the specialization hierarchy. Concept B is
said to specialize concept A if B is a kind of A. There is a single
designated root concept, and all concepts participate in the
specialization hierarchy. It is essentially the IS-A hierarchy used
as a basis of conventional semantic networks. It is used so that
components (see below) may be described at a single concept and
inherited by all the children of that concept. The specialization
hierarchy is more general than the conventional IS-A network in that
it is possible for a concept to specialize more than one other
concept, thus inheriting properties from all its parents. This
feature is termed multiple inheritance.
The second hierarchy is the aggregation hierarchy. In this hierarchy,
the children of a concept are its components, and taken as an
aggregate they completely define that concept. In some cases these
children are not components in a literal sense, but are properties, as
for example the wall voltage required by a device may be a property of
that device. A link in this hierarchy consists of an object called a
role which names the component, together with a connection to the
owner of the role and another connection to the type of the role
(which is another concept).
The final constituent of a KNET structure is the constraint. A
constraint is a piece of executable code attached to the network. The
code is available for use by a program using KNET (an application);
whether, when, and how it is used is up to the application. A
constraint is housed at some particular concept, and refers to one or
more roles. Exactly one of the roles referred to by a constraint is
designated as the trigger of the constraint; the remaining roles are
the targets of the constraint. The purpose of the trigger is to
provide a means for indicating within the KNET structure when an
application program should use a constraint. The meaning of a
constraint is always defined relative to the context in which the
constraint occurs. This means that references to roles made from
within an inherited constraint always refer to the local context
rather than to the context in which the constraint was originally
defined.
Finally, it is important to maintain consistency in knowledge
networks. The definition of consistency varies for differing kinds of
knowledge representation, and depends on the semantic model
implemented by the knowledge representation. For KNET, a fundamental
consistency requirement is the subsumption requirement, defined as
follows: If concept A has a role R with type B, and if concept A2
specializes A, then the type of the inherited role R2 must be B or a
specialization of (a specialization of ...) B. If this requirement is
not met, a subsumption violation is said to occur. The program which
builds KNET structures, the Browser/Editor, automatically checks for
and disallows subsumption violations and several other types of
inconsistencies.
KNET has been implemented in a standard subset of Prolog which has
allowed it to be ported to several different Prolog systems on a
variety of machines. Versions of KNET run on VAXes, Suns, Lisp
machines and PCs. An interactive browser/editor system for KNET
knowledge bases can use a simple ASCII terminal interface, enabling
its use on each of these machines. A more sophisticated graphical
browser/editor is available for use on Sun workstations.
-- Tim Finin
------------------------------
Date: 17 Jun 88 02:44:14 GMT
From: shardy@teknowledge-vaxc.arpa (Steve Hardy)
Subject: Knowledge representation and Prolog
Jerry Harper asks about knwoledge representation languages
written in Prolog (besides APES.)
Teknowledge developed a prolog-based expert system shell called
M.1. It was released in June 1984 and has sold close to 4,000
copies.
M.1 is unusual in that it is a complete logic programming
language as well as being an easy-to-use expert system shell.
For example:
/* --- simple EMYCIN-like heuristic rule --- */
if main-component-of-meal = beef
then best-color-of-wine = red cf 75.
/* --- list processing --- */
infix <>. /* for "append" */
[] <> LIST = LIST.
if LIST1 <> LIST2 = LIST3
then [ITEM|LIST1] <> LIST2 = [ITEM|LIST3].
/* --- objects and inheritance --- */
issquare(obj-22).
size(obj-22) = 5.
if isrectangle(X) and
height(X) = H and width(X) = W and H * W = R
then area(X) = R.
if issquare(X) then isrectangle(X).
if issquare(X) and size(X) = S then height(X) = S.
if issquare(X) and size(X) = S then width(X) = S.
After releasing four versions of M.1 in Prolog, Teknowledge
recoded the system in C. This led to the system being
approximately five times faster and able to handle knowledge
systems five times larger (up to 2000 rules on a 640K IBM-PC.)
It was easier to work out the design of M.1 with Prolog than it
would have been with C.
-- Steve Hardy
------------------------------
Date: 1 Jul 88 01:15:52 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Subject: An example from "Knowledge Systems & Prolog"
Yesterday I bought a copy of
[A Logical Approach to Expert Systems and Natural Language Processing]
Knowledge Systems and Prolog
Adrian Walker, Michael McCord, John Sowa, & Walter Wilson
Addison-Wesley 1987
ISBN 0-201-09044-9
I haven't had time to read much of it yet.
There's some rather good advice in it, and it is easily the most
powerful argument I have ever seen for Edinburgh syntax.
For now I'd just like to comment on one particular example, found
found on page 413. I'll transliterate it into Edinburgh syntax.
% most_general_terms(Terms, GeneralTerms)
% is true when GeneralTerms is the set of terms in Terms which are
% subsumed by no other term in Terms.
most_general_terms(Terms, GeneralTerms) :-
qsort(Terms, TermsInOrder),
most_general_terms_in_order(TermsInOrder, GeneralTerms).
% most_general_terms_in_order(TermsInOrder, GeneralTerms)
% is just like most_general_terms/2, except that less general terms
% precede more general terms in TermsInOrder (that is, if X and Y
% are both in TermsInOrder and X subsumes Y, X must follow Y). The
% order of terms in the result is the same as the order in the input.
most_general_terms_in_order([], []).
most_general_terms_in_order([Term|Terms], GeneralTerms) :-
member(MoreGeneral, Terms),
subsumes(MoreGeneral, Term),
!,
most_general_terms_in_order(Terms, GeneralTerms).
most_general_terms_in_order([Term|Terms], [Term|GeneralTerms]) :-
most_general_terms_in_order(Terms, GeneralTerms).
% This version of quicksort is supposed to order its input so that
% if X and Y are both given and X subsumes Y, X will follow Y in
% the output.
qsort(Terms, TermsInOrder) :-
qsort(Terms, TermsInOrder, []).
qsort([], L, L).
qsort([Term|Terms], L0, L) :-
partition(Terms, Term, Before, After),
qsort(Before, L0, [Term|L1]),
qsort(After, L1, L).
partition([], _, [], []).
partition([Term|Terms], Pivot, Before, [Term|After]) :-
subsumes(Term, Pivot),
!,
partition(Terms, Pivot, Before, After).
partition([Term|Terms], Pivot, [Term|Before], After) :-
partition(Terms, Pivot, Before, After).
%---- end of first version
Now, my antipathy to (falsely so-called) "quicksort" is well known by now.
But in this case its quadratic worst case hardly matters, because if there
are N terms initially, most_general_terms_in_order/2 will do O(N**2) calls
to subsumes/2 anyway. So we might as well do
most_general_terms(Terms, GeneralTerms) :-
most_general_terms(Terms, [], GeneralTerms).
% At each call of most_general_terms(T, G, X)
% there is a list L such that append(L, T, Terms) and
% most_general_terms(L, G).
most_general_terms([], GeneralTerms, GeneralTerms).
most_general_terms([Term|Terms], GeneralTerms0, GeneralTerms) :-
knock_out(GeneralTerms0, Term, GeneralTerms1),
most_general_terms(Terms, GeneralTerms1, GeneralTerms).
knock_out([], Pivot, [Pivot]).
knock_out([Term|Terms], Pivot, GeneralTerms) :-
subsumes(Pivot, Term),
!,
knock_out(Terms, Pivot, GeneralTerms).
knock_out([Term|Terms], Pivot, [Term|Terms]) :-
subsumes(Term, Pivot),
!.
knock_out([Term|Terms], Pivot, [Term|GeneralTerms]) :-
knock_out(Terms, Pivot, GeneralTerms).
%---- end of second version
This has the nice property that the order of terms in GeneralTerms is
exactly the same as the order of terms in the original Terms list,
apart from the deletion of subsumed terms. It does at most N(N-1)
calls to subsumes/2, and while the version of Walker et alia does
at most (1/2)N(N-1) such calls in most_general_terms_in_order/2,
it may do a similar number in partition/4. Indeed, because subsumes/2
is a partial order (not a total order), it is likely to fail rather more
often than it succeeds, so partition/4 is likely to put most of its
first argument into the Before list, and quadratic behaviour is very
likely. (In fact, whenever subsumes(Term, Pivot) succeeds, that tells
us that Pivot will not be in the final result, so we might as well drop
it.)
Actual measurements show that the two versions do about the same number
of calls to subsumes/2: both tend to be close to N(N-1) calls. Sometimes
the "unsorted" method does much better than the "sorted" one, sometimes it
does a little worse.
This is actually a very interesting problem. It crops up in all sorts of
guises. I currently have an algorithm which does at most N(N-1) calls to
subsumes/2 and reduces to at most 2(N-1) when subsumes/2 happens to be
total. If anyone knows of a better algorithm I would be _very_ interested
to hear of it.
------------------------------
Date: Fri, 1 Jul 88 17:30:43 PDT
From: quintus!ok@Sun.COM (Richard A. O'Keefe)
Subject: "Knowledge Systems in Prolog", more examples
Well, I've read more of the Walker, McCord, Sowa, & Wilson book,
and while I still say that there is some good advice in it, there are
one or two things it would pay you *NOT* to imitate.
(1) Wrappers.
On pp 34-35, we are told that the Pascal declaration
type person =
record
name : string;
address : string;
date_of_birth : array [1..3] of integer;
sex : boolean;
end {record};
-- which, by the way, is not a brilliant piece of Pascal --
introduces a type instances of which have as Prolog equivalents
terms of the form
person(name(N), address(A), date_of_birth(D.M.Y), sex(S))
Again, on page 51 we are shown
/* Prolog structure */ { Pascal record }
type loc =
loc( record
farmer(F), farmer : string;
wolf(W), wolf : string;
goat(G), goat : string;
cabbage(C) cabbage : string;
) end {record};
-- which, in context, is an amazingly bad piece of Pascal --
DON'T *DO* THIS! Supposing F, W, G, and C to be constants,
the representation they recommand would cost 13 words in Quintus
Prolog (18 words in another Prolog I know of), whereas the
sum-of-products approach yields the *real* equivalent of the
Pascal record as
loc(Farmer, Wolf, Goat, Cabbage)
at a cost of 5 words in Quintus Prolog (6 in another Prolog).
That's a substantial waste of space and time, and worse still,
it confuses the reader, because when you see patterns like
loc(farmer(F),_,_,_)
and loc(_,wolf(W),_,_)
floating around, your natural assumption is that patterns like
loc(wolf(W),_,_,_) and loc(_,farmer(_),_,_) may be possible, for
why else would anyone have unary wrappers if not to distinguish
such cases?
(2) Over-use of "."
At least in chapter 2, the book has an excessive fondness for ".".
Consider the birth_date(Day.Month.Year) example above. This would
be better as date(Year,Month,Day) --when, amongst other advantages,
it will sort properly-- at a space cost of 4 cells, which is
admittedly the same as the cost of Day.Month.Year. The big
advantage here is that all things made out of dots look alike, so it
is very hard for a human reader to tell D.M.Y from any other X.Y.X,
but date(Y,M,D) proclaims its nature to the world. On page 55, this
book actually _recommends_ X.Y, X.Y.Z and the like, so this was not
an accidental slip but a matter of policy.
The authors have finally cured me of my lingering fondness for infix dot.
I am now thoroughly convinced that bracket notation is to be preferred.
Perhaps if I had been reading Lee Naish's code I might have been swayed
the other way, but I fear that he may not be typical.
(3) Factorial
On page 36 they present the following code:
factorial(0,1).
factorial(N,X) <- lt(N,0) &
write('Negative input to factorial').
factorial(N,X) <- (M := N - 1) & factorial(M,Y) &
(X := N * Y).
{Note: * in VM/Prolog is usually an anonymous variable, but not here.}
What's wrong with this? Well, according to this, factorial(-1, 472)
is true. {For the benefit of those fortunate enough not to have
VM/Prolog, try
factorial(0, 1).
factorial(N, X) :-
N < 0,
write('Negative input to factorial.'), nl.
factorial(N, X) :-
M is N-1,
factorial(M, Y),
X is N*Y.
} For real fun, try factorial(1, 2). If you are going to print an
error message like this, you should at least have the decency to fail.
So the second clause would have been better as
factorial(N, *) <- lt(N,0) &
write('Negative input to factorial') & / & fail.
(4) (falsely so-called) "quick" sort
Section 2.4.1 (p89) starts out admirably, saying that "The choice of
algorithm is the most important factor in determining performance".
But the example they consider is sorting, and they say "Three
different algorithms might be considered:
- a permutation sort that tries all possible permutations of a
list in order to find one that is sorted
- a bubble sort that interchanges pairs of elements until the
result is sorted
- a version of Quicksort ..."
I am really getting thoroughly sick of "quick" sort. Remember, if you
check the fine print in Knuth, Sedgewick, Melhorn, or any good book
on the subject, you will find that the average case of "quick" sort
does about 1.4 times as many comparisons as the WORST case of merge sort.
If people are going to presume to give advice about sorting, they might
at least check the standard literature. (Not that sorting is a major
topic in Walker et al, but it wasn't a major topic in Clocksin&Mellish
either, and that didn't stop people mistaking the difference-list
example for advice about how to sort.)
(5) Breadth-first search.
On pp 82-83 we find
breadth_first(Goal, Histories, Answer) <-
member(Goal.Past, Histories) &
reverse(Goal.Past, Answer).
breadth_first(Goal, Histories, Answer) <-
Histories=(*,*) &
set_of(Next.Current.Past,
member(Current.Past, Histories) &
move(Current,Next) & \member(Next,Past),
New_history_list) &
remove_duplicate_head(New_history_list, Clean_list) &
breadth_first(Goal, Clean_list, Answer).
remove_duplicate_head(F.S.Tail, Clean) <-
((F=(Head.*) & S=(Head.*)) ->
remove_duplicate_head(F.Tail,Clean);
(remove_duplicate_head(S.Tail,L) &
Clean=(F.L))).
remove_duplicate_head(F.nil, F.nil).
remove_duplicate_head(nil, nil).
Let's start with remove_duplicate_head. The input is a list of lists,
which is sorted, and subsequences ...,[A|T1],...,[A|Tn],... with the
same head (A) are to be replaced by the first member of the subsequence
(here [A|T1]). Can we do this more cleanly?
remove_duplicate_heads([], []).
remove_duplicate_heads([[Tag|Info]|Given], [[Tag|Info]|Clean]) :-
skip_duplicate_heads(Given, Tag, Clean).
skip_duplicate_heads([[Tag|_]|Given], Tag, Clean) :- !,
skip_duplicate_heads(Given, Tag, Clean).
skip_duplicate_heads(Given, _, Clean) :-
remove_duplicate_heads(Given, Clean).
In Quintus Prolog, the cleaner version is about three times faster.
I think the test \member(Next, Past) might perhaps be better as
\member(Next, Current.Past), in case the problem graph has self-loops.
If you are given a generation function which yields all of the children
of a node at once instead of a move/2 which enumerates them, you can
write breadth first search without appealing to set_of/3 at all.
{The predicate called set_of/3 in this book corresponds to the
predicate called set_of_all/3 in the Quintus library, not to the
predicate called set_of/3, except that set_of_all/3 checks that it
is being called soundly, and set_of/3 in this book doesn't.}
Reminder:
In this note I've concentrated on some of the infelicities in the book.
I repeat that there is a lot of good stuff in it, and on the whole I do
not regret its purchase.
------------------------------
Date: Sat, 2 Jul 88 22:03:31 PDT
From: quintus!ok@Sun.COM (Richard A. O'Keefe)
Subject: "Knowledge Systems and Prolog", chapter 3
Yes, it's me again, with yet a third set of comments on the
"Knowledge Systems and Prolog" book by Walker, McCord, Sowa, & Wilson.
This particular set of comments pertains to chapter 3. I hasten to
say at the outset that there is a lot of good stuff in this chapter
which I wish I had written myself, but of course I have nothing to
say about _that_.
1. Logic Programming Development Process (pp 110-111)
Don't take steps 1..9 too seriously; that's not how I do it, and
one of the most important steps has been omitted, namely "check to
see if someone else has already solved the problem". But the rest
of the advice on p111 is good.
2. Reading (p 113)
The book presents two fragments (recast here as Prolog):
...
read(Stream1, X),
read(Stream2, T),
process(X, T)
...
and
...
customer(Name),
catalogue_item(Item),
interested_in(Name, Item),
send_letter(Name, Item)
saying "For example, catalogue_item/1 may simply read the next term".
Now the second fragment looks as though it has a declarative reading.
But its behaviour is radically different from the behaviour which
would result if customer/1 and catalogue_item/1 were tables. It is
_NOT_ good style to give commands with side effects names which suggests
that they are pure relations. In fact it is very bad style. Suppose
we had the customer and catalogue_item tables in memory as pure
relations, and wrote this failure-driven loop:
send_letters :-
customer(Customer),
catalogue_item(Item),
interested_in(Customer, Item),
send_letter(Customer, Item),
fail
; true.
This would combine *every* Customer with *every* catalogue Item.
But the original fragment with the two read commands doesn't do that;
it reads an X and a T and combines _that_ X with _that_ T and no other.
By the way, you _can_ keep (a small number of) tables in files and
access them with read/1. Here's an example (using Quintus Prolog):
:- dynamic
table_stream/2.
initial_position('$stream_position'(0,1,0)).
read_from_external_relation_1(Table, Entry) :-
( table_stream(Table, Stream) -> true
; external_relation(Table, FileName),
open(FileName, read, Stream),
assert(table_stream(Table, Stream))
),
initial_position(Zero),
do_external_access(Zero, Stream, Entry).
do_external_access(Before, Stream, Entry) :-
stream_position(Stream, _, Before),
read(Stream, Term),
stream_position(Stream, After),
( Term == end_of_file -> fail
; Entry = Term
; do_external_access(After, Stream, Entry)
).
external_relation(customer, 'custom.dat').
external_relation(catalogue_item, 'catalo.dat').
customer(Customer) :-
read_from_external_relation_1(customer, Customer).
catalogue_item(Item) :-
read_from_external_relation_1(catalogue_item, Item).
Now, this _is_ a version of catalogue_item/1 which "simply read[s]
the next term", but it is pretty remote from the first fragement.
I don't know whether Frank McCabe invented this technique, but he's
the one I got it from (testing the code above was the first time I
have ever _used_ the technique, mind...).
If you can possibly fit the information into memory, _do_ it.
Don't keep reading it from a file over and over again. Another
possibility, instead of using read_from_external_relation_1/2,
would be to read a file once and build an index in memory, so
that fewer reads would be done.
For example, suppose we have a a file 'passwd.pl' containing items like
passwd(teksup,123,45,'Tech Support', '/peano/teksup','/bin/csh').
passwd(halt, 6, 7,'Stop Machines', '/', '/etc/halt').
passwd(ok, 89,10,'Richard A. O''Keefe','/dedekind/ok', '/bin/csh').
{Crackers beware: these are _not_ real Quintus /etc/passwd entries!}
We might do this:
:- dynamic
passwd_stream/1,
passwd_index/2.
initialise_passwd(Stream) :-
open('passwd.pl', read, Stream),
assert(passwd_stream(Stream)),
repeat,
stream_position(Stream, Position),
read(Stream, Term),
( Term = passwd(Key,_,_,_,_,_) ->
assert(passwd_index(Key, Position)),
fail
; true
),
!. % The Stream is left open!
passwd1(Key, Uid, Gid, Name, Home, Shell) :-
( passwd_stream(Stream) -> true
; initialise_passwd(Stream)
),
passwd_index(Key, Position),
stream_position(Stream, _, Position),
read(Stream, passwd(Key,Uid,Gid,Name,Home,Shell)).
It is fair to give a predicate so defined a name which suggests
that it is a pure table, because (apart from tying up a stream and
being rather slow) that's how it _acts_.
ONLY use this technique if you can build a good index; it can be
hundreds, even thousands, of times slower than accessing tables in
main memory.
3. Wrappers (page 114-115)
There is an example on pp 114-115 which reads thus:
name(Name, TelephoneNumber, File) :-
get_next_record(File, Record),
parse_record(Record, name(Name,TelephoneNumber)).
↑↑↑↑↑ ↑
parse_record(Record, name(Name,TelephoneNumber)) :-
↑↑↑↑↑ ↑
parse_name(Name, Record, Rest_of_record),
parse_blanks(_, Rest_of_record, Last_of_record),
parse_telephone(TelephoneNumber, Last_of_record, _).
{If you look at the code in the book, you'll see that the first
argument of parse_blanks/3 is an anonymous variable in all calls
and definitions, so it might as well not be there.}
There is much to quarrel with in the choice of names here:
the parse_*** predicates are genuinely relational, so should have
noun-phrase or adjective-phrase names, not names that look like
commands. Worst of all, the operation which _is_ a command (that
is, which has a side effect) is given the name name/3 which looks
like a pure relation. It would be better named e.g.
read_name_and_phone_number(File, Name, PhoneNumber)
My main point here is that name(_,_) is a useless wrapper. If the
name and phone number had to be returned to the caller so packaged,
there'd be some sense in it, but not here. It would be better as
read_name_and_phone_number(Stream, Name, PhoneNumber) :-
get_line(Stream, Chars),
name_and_phone_number(Name, PhoneNumber, Chars, _).
name_and_phone_number(Name, Exchange-Extension) -->
token(Name),
blanks,
number(Exchange), "-", number(Extension).
where the compound term -(_,_) here _is_ justified because that's
what the caller wants.
4. Query-the-user (pp 116-117, p120).
When you hit page 116, look ahead to page 120. I'll not comment on
the rather major problems of the code on page 116, because the code
on page 120 remedies some of them.
The idea is that you want a relation user('User''s first name')
-- by the way, I find it offensive to have computers address me by
my first name, so whenever a program asks me my first name I lie;
my computer account name will do fine for any genuine identification--
but you don't want to ask unless you turn out to need the information.
The code on page 120 is (converted to Quintus Prolog):
:- dynamic
known/1.
user(Name) :-
known(user(Name)),
!.
user(Name) :-
prompted_line('What is your first name? ', Chars),
( verify(Chars) -> % you have to supply verify/1
atom_chars(Name, Chars),
assert(known(user(Name)))
; format('~s: not verified.~n', [Chars]),
user(Name)
).
{This is not identical to the code in the book, but it has the same
kinds of bugs, which is what I'm concerned with.}
I loaded this into Quintus Prolog, together with library(prompt)
and this definition of verify/1:
verify([_,_]).
Now see what happens:
| ?- user(fred).
What is your first name? jim
jim: not verified. % right
What is your first name? ok
no % right, BUT
| ?- listing(known/1). % prints _nothing_
| ?- user(Who). % should pick up 'ok', BUT
What is your first name? ok % it asks AGAIN!
Who = ok % but that's not all...
| ?- user(dz).
What is your first name? ok % it asks yet AGAIN!
no
The code breaks down in (at least) two ways:
A) If we call it with Name bound when known(user(X)) is true--i.e.
the user has been asked for his name--but X\==Name, the user
will be asked for his name again. Fortunately, the _second_
breakdown then occurs, so at least it isn't _stored_ again.
B) If we call it with Name bound when the user name is not known
(or when it is known to be different from Name), we'll ask for
the name, verify it, and then fail before storing the name.
How should it be written?
:- dynamic
property_known/2.
property_type(user, atom).
...
property_prompt(user, 'What is your first name? ').
...
property_verify(user, Chars) :-
verify_user(Chars).
...
simple_query(Property, Value) :-
simple_query_1(Property, X),
Value = X.
simple_query_1(Property, Value) :-
property_known(Property, Value),
!.
simple_query_1(Property, Value) :-
property_type(Property, Type),
simple_query_1(Type, Property, Value),
assert(property_known(Property, Value)).
...
simple_query_1(atom, Property, Value) :-
property_prompt(Property, Prompt),
repeat,
prompted_line(Prompt, Chars),
( property_verify(Property, Chars)
; format('~s: not verified~n', [Chars]), fail
),
!,
atom_chars(Value, Chars).
...
user(UserName) :-
simple_query(user, UserName).
Now, with this definition, we get
| ?- user(fred).
What is your first name? jim
jim: not verified
What is your first name? ok
no
| ?- listing(property_known/2).
property_known(user,ok).
yes
| ?- user(Who).
Who = ok
| ?- user(dz).
no
which is what you would expect something like this to do.
5. "Global variables" (p122)
I have to quote their VM/Prolog code here, because delax/1 doesn't
behave quite like retract/1, more like retract_first/1.
A ::= B <-
try(delax(global_value(A, *))) &
addax(global_value(A, B)).
try(X) <- X.
try(*).
What's wrong with this? Well, after converting to Quintus Prolog,
I got the following result:
| ?- x ::= 1, listing(global_value/2).
global_value(x,1).
| ?- x ::= 2, global_value(x, 1).
no
| ?- listing(global_value/2).
global_value(x, 2).
global_value(x, 2).
I'll leave you to figure _that_ one out for yourselves, but the
moral is that any time the last clause of a predicate is a
catch-all case like the last clause of try/1, the chances are
someone is trying to be clever and failing.
6. Another steadfastness problem (p122)
We are told on page 122 that "the global_value/2 technique
described above can be used to simulate a stack, as follows:
push(Stack, Item) <-
addax(global_value(Stack, Item), 0). % "asserta"
pop(Stack, Item) <-
delax(global_value(Stack, Item)).
The predicates push/2 and pop/2 have their obvious meaning."
Actually, they haven't. Or at any rate pop/2 hasn't. If pop/2
succeeds, it did delete an item from the stack, but the item it
deleted may not have been at the top of the stack... Working
Prolog code is
push(Stack, Item) :-
asserta(global_value(Stack,Item)).
pop(Stack, Item) :-
retract(global_value(Stack,Top)),
!,
Item = Top.
top(Stack, Item) :-
global_value(Stack, Top),
!,
Item = Top.
TO BE CONTINUED
I have about as much more to add, but it's time to go home.
DISCLAIMER
Remember, I'm criticising slips in a by-and-large-reasonable book;
the good stuff can speak for itself.
You'll recall that I had very little to criticise in the _content_
of the Warren & Maier book, but raged about the misleading preface
and blurb. I recommended it to the Prolog class I taught last week,
and if I had bought the Walker et al book by then I'd probably have
suggested it to them as worth reading too. Yes, I've made up my
mind, I _shall_ recommend it to the next Quintus class, if only to
show them why they should buy QP370 rather than VM/Prolog (:-).
---------------------------------
End of PROLOG Digest
∂15-Jul-88 2152 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #45
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Jul 88 21:52:45 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA26241; Mon, 11 Jul 88 11:39:00 PDT
Date: Mon, 11 Jul 88 11:39:00 PDT
From: Chuck Restivo <restivo@polya.Stanford.EDU>
Message-Id: <8807111839.AA26241@polya.Stanford.EDU>
To: restivo@polya.Stanford.EDU
Subject: PROLOG DIGEST V6 #45
Date: Monday, 10 July 1988 02:53-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@POLYA.STANFORD.EDU>
Reply-to: PROLOG@POLYA.STANFORD.EDU>
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #45
To: PROLOG@POLYA.STANFORD.EDU
PROLOG Digest Monday, 11 July 1988 Volume 6 : Issue 45
Today's Topics:
Query - Clue,
Announcement - Poplog Conference
-----------------------------------------------------------------------------------------------------------------------------
Date: 1 Jul 88 07:11:00 EDT
From: "CUGINI, JOHN" <cugini@ecf.icst.nbs.gov>
Subject: Free code for Clue ?
Didn't someone somewhere once submit a Prolog Clue-player?
(Prof. Pum did it with a Rope in the Ballroom...)
Whether or not he did, does anyone have such code they'd
like to share? I started trying to do this and I figured
it would take a while, not because of the deductive part of
the game, but because of the board moves (which room to aim
for next ?).
Thank you.
-- John Cugini
------------------------------
Date: 1 Jul 88 14:30:12 GMT
From: mcvax!ukc!reading!onion!henry!jadwa@uunet.uu.net (James Anderson)
Subject: POPLOG Conference
You are probably aware of POPLOG. It is a software environment
running on many UNIX and VMS machines. If you would like to see
POPLOG in action then come to the POPLOG Users' Forum conference
at Reading University, Berkshire, England this July 19 and 20.
Day attendance costs ten pounds, accommodation twenty pounds and
an evening "banquet" ten pounds. So the conference is a very cost
effective way of getting information about a very effective
software environment. If you would like more details then please
mail me.
Here are some of the things that POPLOG provides.
1) Full on-line documentation. Includes teaching material,
help files, reference files and system documentation. The
teaching material covers basic programming techniques and
AI subjects such as linguistics and vision.
2) The incrementally compiled languages: POP11, PROLOG and
COMMON LISP. Object oriented programming is also
supported. ML comes as an optional extra.
3) A visual editor which is:
a) Sensitive to the languages' syntax, to aid editing.
b) Interfaced to the incremental compilers and
de-bugging tools, to aid program development.
c) Interfaced to the UNIX/VMS command line interpreters to
allow system administration from within the POPLOG
environment.
4) A generic, networked window interface which is supported
by the host
--------------------------------
End of PROLOG Digest
∂15-Jul-88 2301 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #44
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Jul 88 23:01:26 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA25898; Mon, 11 Jul 88 11:37:06 PDT
Date: Mon, 11 Jul 88 11:37:06 PDT
From: Chuck Restivo <restivo@polya.Stanford.EDU>
Message-Id: <8807111837.AA25898@polya.Stanford.EDU>
To: restivo@polya.Stanford.EDU
Subject: PROLOG DIGEST V6 #44
Date: Mon, 11 Jul 1988 02:53-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@POLYA.STANFORD.EDU>
Reply-to: PROLOG@POLYA.STANFORD.EDU>
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #44
To: PROLOG@POLYA.STANFORD.EDU
PROLOG Digest Monday, 11 July 1988 Volume 6 : Issue 44
Today's Topics:
Query - dBase III,
Implementation - VAX/VMS Review
------------------------------------------------------------------------------------------------------------------------------
Date: 24 Jun 88 18:29:32 GMT
From: uccba!ucqais!bbeck@tut.cis.ohio-state.edu (Bryan Beck)
Subject: Query Dbase III Plus with Turbo Prolog
I recently read an article in AI EXPERT, June 1988 written by Karl Horak about
using Turbo Prolog to query Dbase III Plus files. There were two points that
were not clearly delineated in the article, (1) How to get prolog to read the .dbf and
how to get prolog to read the .dbt files.
Also the article referencing Fileman, Rick. "Memo to Character Conversion,"
Aston-Tate Inc. TechNotes, Nov. 1987,pp 15-24.
I any one has read this article of have done anything like this, or where I can find these TechNotes. I would greatly appreciate any additional information
about trying to do this.
Thank you.
------------------------------
Date: 29 Jun 88 14:37:22 GMT
From: mcvax!ukc!dcl-cs!simon@uunet.uu.net (Simon Brooke)
Subject: Survey of Prologs for VMS VAX
About 10 days ago, I put out a message asking people to recommend PROLOGs
for VAX VMS. Many thanks to all those who replied. I'm posting (in case
anyone else is interested) what I learned. Brief word of explanation: I
was asked to select a PROLOG in which it would be possible to construct an
interface to a relational database mangement system, and the report is
heavily biased to reflect this need.
PROLOGs available for VAX/VMS:
A brief review, with regard to the needs of the Savant
project.
How systems were selected for inclusion into this report
In order to find as many VMS compatible PROLOGs as
possible, in the shortest possible time, I posted to the
USENET newsgroup comp.lang.prolog, on the basis that all
serious PROLOG developers would inevitably keep an eye on
this. This method appears to have was only partially
partially successful, in that it produced reviews of most
of the systems I was already aware of, including systems I
wasn't aware were available for VMS. However, it didn't
produce any news of systems I don't know about, and there
may still be some of those.
I also consulted the news section of the Journal 'Expert
Systems', going back two years.
What I asked for
The message which I posted asked respondents to tell me:
* What syntax it uses - especially, how like Quintus it is.
* What the 'foreign function interface' is like.
* Roughly what the performance is like.
* What the programmer's environment is like . . .
* How robust it is - and any points to watch...
* What it costs and from whom (UK supplier if possible)
The systems included
The systems which I received replies about were as follows
(in the order I received them):
Edinburgh Prolog
Quintus Prolog (two replies)
BIM_Prolog (two replies)
Poplog
On the whole, replies were directly from implementors, and,
although they may be somewhat more honest than promotional
literature, cannot be considered independent.
I also have received promotional material describing
LPA Sigma Prolog
and have found a news item describing
I/F Prolog.
Experience of the systems
I have been able to play with Quintus (on Suns under Unix),
Edinburgh (on VAX under Unix), and Poplog (on Suns under
Unix).
Quintus
This is the only one of the systems I have any significant
experience with. Quintus is a widely used - and in general
widely liked - version of a vanilla flavoured Edinburgh-
syntax PROLOG. After LISP machines, the EMACS based
development environment strikes me as so wretchedly crude
as to be almost unusable. However, by using system editors,
code can be developed reasonably quickly.
The system is relatively fast, and appears well thought out
and solid. I imagine that, on a Xerox workstation, this is
a very nice system.
Edinburgh
I have played only briefly with Edinburgh Prolog. I loaded
in the dBAccess code, most of which ran. However, the use
of the token 'not' as a negation operator is apparently not
permissible in Edinburgh prolog, and, as I did not have a
manual, I was unable to attempt to patch this.
There appears to be no compiler.
My feeling, however, is that it would be trivial to port to
Edinburgh Prolog. Whether any particular development
environment tools are supplied I can't say; but if not,
they aren't strictly needed.
Poplog
Again, I have experimented only briefly with Poplog. My
first impression was of quite remarkable slowness. Whilst
the reader of the Edinburgh system skipped over the
declarations in the (Quintus) files containing the dBAccess
code which it could not understand (because they were
Quintus specific), the Poplog reader aborted. Thus these
files could not be loaded without some editing.
Again, the syntax of 'not' differed from Quintus; in Poplog
prolog, 'not' is a one place predicate rather than a prefix
operator.
Once the files had been edited, they loaded satisfactorily,
and again, very nearly ran. Again, there appeared to be no
compiler.
Discussion
Relative performance
I don't have any good comparative figures on the relative
performance of these systems. However, what I have is as
follows:
Version KLips Hardware KLips Test Syntax Price
/Mips
Edin 2.2 VAX 750/Unix 3.66 N.Rev Edinburgh #1000
BIM 26 VAX 750/VMS 43.33 N.Rev proprietary #8150
85 Sun 3 42.5 ?? [Edin optional]
Sigma 6.9 Sun 3 3.45 ?? Lisp-based #750 [one user]
[Edin optional]
Quintus 60 Sun 3 30 N.Rev Edinburgh #4200
I/F 90 Sun 3 45 ?? Unknown #11000
40 VAX 780 ?? ??
Poplog 4.5 VAX 750 7.5 ?? Edinburgh #12000
As the Sun is rated at about 2 Mips, and the VAX 750 at
0.6 Mips, this suggests that I/F may be fastest of all,
with LPA Sigma slowest; the column KLips/Mips uses this
estimation to try to produce a normalised speed for each
implementation. Also, these figures come from various
different sources, and reflect different peoples
benchmarks; they may not be directly comparable.
Nevertheless, the fastest PROLOGs are clearly very much
faster than the slowest. This at least partly reflects the
fact that some of these systems are interpreters only,
while some have compilers. Certainly Sigma has no compiler,
and I was unable to find one in either the Edinburgh or
Poplog systems. Given the benchmark speeds quoted, I would
suspect that none of these systems has a compiler, while I
know that all the others do.
Prices and where possible speeds have been verified with UK
suppliers.
Foreign Function Interface
All the systems described with the exception of I/F (about
interfaces to C. Specific claims are as follows:
Edinburgh
"Users can supply C bodies for Prolog predicates - this is
easy under UNIX, as the .o file can be dynamically loaded,
but we are just now doing the decomposition to let the
object file be linked into the executable under VMS (pardon
any terminology errors, VMS isn't my own field)" (source:
Correspondence with implementor)
BIM:
"BIM_Prolog has a complete interface to all procedural
languages which create a standard VAX/VMS object file.
Examples of C and Fortran are delivered with the
distribution" (source: Correspondence from BIM
representative)
"BIM_Prolog has an external language interface, although it
has no dynamic linking: it means that you can link into the
system a package (or more than one) with C functions - or
assembler, pascal, ada ... as long as the linker of VMS can
link the object of BIM_Prolog to it" (source:
correspondence with user)
LPA Sigma:
"A simple to use 'C' language interface allows new
facilities to be added quickly to the basic system"
(source: promotional literature).
Quintus:
The UNIX version of Quintus provides interfaces to C,
Pascal, and Fortran; I have no information to hand about
the VMS version. (source: User Guide)
I/F: no information
Poplog:
The Poplog environment includes LISP, POP-11, and
optionally ML in addition to Prolog, and all these can be
integrated. Additionally, "....you can link in C, Fortran,
or whatever" (source: correspondence from Prof Aaron
Sloman)
Recommendations
I would not at this stage recommend I/F Prolog, as,
although it's performance is reported to be very good, I
don't have adequate information about it; also, it's price
is extremely high. I would not recommend Sigma, as its
performance is just too poor, and this generally reflects
my experience of LPA implementations - nice systems with
dreadful performance. Also, LPA are no longer supporting
Sigma. They plan to have a new implementation out sometime
next year. Of the remaining systems:
Quintus
Quintus is (I believe) the market leader; it is solid, well
behaved and well supported, reasonably fast and not
excessively priced.
BIM
BIM_Prolog has two primary advantages: firstly it is fast;
secondly, it comes with a complete and working database
interface. Although it is more expensive than Quintus, the
benefits of a supplier supported db interface might well
more than make up for this from Savant's point of view (of
course, it would also put me out of a job).
Poplog
Is a very rich environment - far richer than is needed for
the current project. Although a nice product, it is less
suitable for our purposes than BIM, in view of its greatly
inferior speed, and lack of database interface.
Edinburgh
Is adequate for development purposes, and is very cheap.
The project would probably have to buy a faster system when
the time came to construct a marketable product.
Conclusion
Edinburgh PROLOG, plus my salary for as long as it takes to
make Edinburgh do what BIM already does, would probably add
up to a fair proportion of the cost of BIM - for a system
with markedly inferior performance.
So I (were I not me) would buy BIM (I'd want to see it first) - unless a
proprietary database interface is of primary importance; in
which case Edinburgh would do only as a cheap development
system, with Quintus being required for serious product
development.
-- Simon Brooke
--------------------------------
End of PROLOG Digest
∂16-Jul-88 0117 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #39
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Jul 88 01:16:55 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA29361; Sat, 9 Jul 88 07:23:11 PDT
Date: Sat, 9 Jul 88 07:23:11 PDT
From: Chuck Restivo <restivo@polya.Stanford.EDU>
Message-Id: <8807091423.AA29361@polya.Stanford.EDU>
To: restivo@polya.Stanford.EDU
Subject: PROLOG DIGEST V6 #39
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@POLYA.STANFORD.EDU>
Reply-to: PROLOG@POLYA.STANFORD.EDU>
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #39
To: PROLOG@POLYA.STANFORD.EDU
PROLOG Digest Friday, 8 July 1988 Volume 6 : Issue 39
Today's Topics:
Query - Parallel Systems & Data Structures,
Implementation - Disjunction & Screen Control
--------------------------------------------------------------------------------------------------------------------------
Date: 26 May 88 15:07:20 GMT
From: dartvax!eleazar.dartmouth.edu!fagin@bu-cs.bu.edu (Barry S. Fagin)
Subject: Usable parallel logic programming systems
I'm trying to gather information on existing or planned implementations
of parallel logic programming systems, preferably on existing
multiprocessors. If you have any information on such a system, could
you please send me mail about it? Any pointers to documents would be
greatly appreciated. Thanks.
--Barry
------------------------------
Date: 25 May 88 08:43:43 GMT
From: mcvax!unido!ecrcvax!micha@uunet.uu.net (Micha Meier)
Subject: Clause fusion (Disjunctions)
In article <1001@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>In article <539@ecrcvax.UUCP>, micha@ecrcvax.UUCP (Micha Meier) writes:
>> Richard proposes that nested if-then-else's are treated at the same level,
>> which leads to confusions since then the indentation is context dependent
>> (an if-then-else inside another one cannot be indented independently).
>
>I DO NOT! I use exactly the same rule for indenting if->then;elses in
>Prolog that I use in Fortran 77, Pop, ADA, Algol 68, et cetera. Namely
>
> <IF> <condition> <THEN>
> [1 indent] <body>
> <ELIF> <condition> <THEN>
> [1 indent] <body>
> ...
> <ELSE>
> [1 indent] <body>
> <ENDIF>
>
The problem with Prolog is that any of the term can be
a conjunction, disjunction or if-then-else. What about
( ( C1 ->
B1
;
B2
) ->
( C2 ->
B3
;
B4
),
B5
; B6,
B7
)
I find it not much readable when the condition is difficult
to distinguish from the other code.
> ( test1 ->
> body1
> ; test2 ->
> body2
> ; /*otherwise*/
> body3
> )
Here it is different - how exactly do you indent your procedures?
This problem might seem to be a minor one, but should not there
be at least a recommendation from the standard or from somebody
else? Prolog does not have many syntactical structures and therefore
it is extremely important to keep some programming style, e.g.
to use names_like_that for procedures and LikeThat for variables,
to put each goal on a separate line etc. I've been trying to
port various external programs to Sepia and sometimes it's rather
difficult to realize what the author really meant.
--Micha
------------------------------
Date: 27 May 88 00:28:28 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Subject: Clause fusion
In article <548@ecrcvax.UUCP>, micha@ecrcvax.UUCP (Micha Meier) writes:
> The problem with Prolog is that any of the term(s in an if->then;else)
> can be a conjunction, disjunction or if-then-else. What about
> ( ( C1 ->
> B1
> ;
> B2
> ) ->
> ( C2 ->
> B3
> ;
> B4
> ),
> B5
> ; B6,
> B7
> )
Algol 60, Algol 68, Lisp, Pop, Bourne shell, C shell, ML, ... have
exactly the same problem. There's nothing special about Prolog in this
respect. The answer is that it isn't a problem to have another if in a
then-part or else-part, and that programmers who care about readability
don't put ifs in if-parts. The big lesson for Prolog programmers is
"don't be scared of introducing new predicates". Programmers who do not
care about readability will find obfuscatory ways despite standards.
(The famous "Indian Hills style sheet" for C has led to some of the most
unreadable C code it has ever been my misfortune to try to read.)
I basically agree with Meier's concern for readability. But I think the
layout of the Prolog code as such is not the most important aspect. It
is easy to write a reformatter (the editor I'm using to write this has one).
You can fix what is there, the trouble is what _isn't_ there. I have
recently had occasion to look at two people's programs. One of them
I repeatedly misunderstood because it was doing some very tricky things
in its control flow and had essentially no comments. The other I still
do not understand because it is doing non-obvious things with its data
structures and has essentially no comments.
Rules of thumb for comments:
(1) Describe all major data structures.
(2) Comment every control trick.
------------------------------
Date: 28 May 88 06:14:00 GMT
From: mccaugh@m.cs.uiuc.edu
Subject: Re: Clause fusion (Disjunctions)
/* Written 1:14 am May 28, 1988 by mccaugh@uiucdcsm.cs.uiuc.edu in uiucdcsm:comp.lang.prolog */
/* Written 3:43 am May 25, 1988 by micha@ecrcvax.UUCP in uiucdcsm:comp.lang.prolog */
/* ---------- "Re: Clause fusion (Disjunctions)" ---------- */
In article <1001@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>In article <539@ecrcvax.UUCP>, micha@ecrcvax.UUCP (Micha Meier) writes:
>> Richard proposes that nested if-then-else's are treated at the same level,
>> which leads to confusions since then the indentation is context dependent
>> (an if-then-else inside another one cannot be indented independently).
>
>I DO NOT! I use exactly the same rule for indenting if->then;elses in
>Prolog that I use in Fortran 77, Pop, ADA, Algol 68, et cetera. Namely
>
> <IF> <condition> <THEN>
> [1 indent] <body>
> <ELIF> <condition> <THEN>
> [1 indent] <body>
> ...
> <ELSE>
> [1 indent] <body>
> <ENDIF>
>
The problem with Prolog is that any of the term can be
a conjunction, disjunction or if-then-else. What about
( ( C1 ->
B1
;
B2
) ->
( C2 ->
B3
;
B4
),
B5
; B6,
B7
)
I find it not much readable when the condition is difficult
to distinguish from the other code.
> ( test1 ->
> body1
> ; test2 ->
> body2
> ; /*otherwise*/
> body3
> )
Here it is different - how exactly do you indent your procedures?
This problem might seem to be a minor one, but should not there
be at least a recommendation from the standard or from somebody
else? Prolog does not have many syntactical structures and therefore
it is extremely important to keep some programming style, e.g.
to use names_like_that for procedures and LikeThat for variables,
to put each goal on a separate line etc. I've been trying to
port various external programs to Sepia and sometimes it's rather
difficult to realize what the author really meant.
--Micha
------------------------------
Date: 28 May 88 06:14:00 GMT
From: mccaugh@m.cs.uiuc.edu
Subject: Clause Fusion
/* Written 3:43 am May 25, 1988 by micha@ecrcvax.UUCP in uiucdcsm:comp.lang.prolog */
/* ---------- "Re: Clause fusion (Disjunctions)" ---------- */
In article <1001@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>In article <539@ecrcvax.UUCP>, micha@ecrcvax.UUCP (Micha Meier) writes:
>> Richard proposes that nested if-then-else's are treated at the same level,
>> which leads to confusions since then the indentation is context dependent
>> (an if-then-else inside another one cannot be indented independently).
>
>I DO NOT! I use exactly the same rule for indenting if->then;elses in
>Prolog that I use in Fortran 77, Pop, ADA, Algol 68, et cetera. Namely
>
> <IF> <condition> <THEN>
> [1 indent] <body>
> <ELIF> <condition> <THEN>
> [1 indent] <body>
> ...
> <ELSE>
> [1 indent] <body>
> <ENDIF>
>
The problem with Prolog is that any of the term can be
a conjunction, disjunction or if-then-else. What about
( ( C1 ->
B1
;
B2
) ->
( C2 ->
B3
;
B4
),
B5
; B6,
B7
)
I find it not much readable when the condition is difficult
to distinguish from the other code.
> ( test1 ->
> body1
> ; test2 ->
> body2
> ; /*otherwise*/
> body3
> )
Here it is different - how exactly do you indent your procedures?
This problem might seem to be a minor one, but should not there
be at least a recommendation from the standard or from somebody
else? Prolog does not have many syntactical structures and therefore
it is extremely important to keep some programming style, e.g.
to use names_like_that for procedures and LikeThat for variables,
to put each goal on a separate line etc. I've been trying to
port various external programs to Sepia and sometimes it's rather
difficult to realize what the author really meant.
--Micha
------------------------------
Subject: Data Structures
Date: Fri, 27 May 88 14:10:54 -0700
From: Russ Abbott <abbott@aerospace.aero.org>
Date: 22 May 88 22:34:33 GMT
Can anyone refer me to a prolog (or other) system that does data structure
transformations? The general problem is to define interfaces between
pre-exising tools in an environment.
A particular example is to use P-Nut, a petri net analyzer, on a system
produced by Teamwork, a data flow diagrammer. Besides allowing one to draw
data flow diagrams, Teamwork also allows one to draw process activation tables.
For example, the following are two rows in a process activation table.
1. The first row says that if condition C1 holds and condition C4 does
not hold, the processes P1 and P4 should be started. Once they
finish, process P5 should be started.
2. The second row says that if conditions C1 and C2 hold and condition
C3 does not hold, processes P1 and P3 should be activated. When P1
and P3 complete, process P2 should be activated. When it completes
processes P1 and P3 should be reactivated. When they complete a
second time, processes P4 and P5 should be activated.
A complete process activation table would consist of any number of such rows,
each row having a unique distribution of +'s and -'s among the conditions.
C1 | C2 | C3 | C4 || P1 | P2 | P3 | P4 | P5
----+----+----+----++----+----+----+----+----
+ | | | - || | 1 | | 1 | 2
+ | + | - | || 1,3| 2 | 1,3| 4 | 4
....
The petri net input to say the same thing looks like the following.
C1, not C4 -> row({C1, not C4},1), P2s, P4s
row({C1, not C4},1), P2f, P4f -> row({C1, not C4},2), P5s
row({C1, not C4},2), P5f -> <empty>
C1, C2, not C3 -> row({C1, C2, not C3},1), P1s, P3s
row({C1, C2, not C3},1), P1f, P3f -> row({C1, C2, not C3},2), P2s
row({C1, C2, not C3},2), P2f -> row({C1, C2, not C3},3), P1s, P3s
row({C1, C2, not C3},3), P1f, P3f -> row({C1, C2, not C3},2), P4s, P5s
row({C1, C2, not C3},3), P4f, P5f -> <empty>
P1s -> P1f
P2s -> P2f
P3s -> P3f
P4s -> P4f
P5s -> P5f
where (a) P1s, P2s, P3s, P4s, and P5s stand for the start of P1, P2, P3, P4,
and P5; (b) P1f, P2f, P3f, P4f, and P5f stand for the finish of the same
processes; and (c) row(<conditions>, <level>) stands for the row identified by
the indicated set of conditions, executing at the indicated level. Of course,
the actual row conditions are not needed to identify the row. All that is
needed is some unique identifier for each row.
So the problem is to transform the information from table form into petri net
form.
The question, though, is not how to write a program for this particular
transformation, but to develop a more general system in which transformations
of this and similar kinds can be described and implemented.
I have already found the following work.
1. IDL, an Interface Description Language by David Alex Lamb of Queens
University. IDL was developed as part of CMU's Production Quality
Compiler Compiler project. It allows one to describe abstractly the
data structures that two system components agree on. (Since the
components agree on a data structure, this problem is not the same
as the one I'm asking about.) IDL then generates reader and writer
code for that abstract data structure in whatever concrete terms the
two components require. IDL is described in "IDL: Sharing
Intermediate Representations,", TOPLAS, July, 1987.
2. FORMAL a system for transforming hierarchical databases. In FORMAL,
one provides a description of an input database along with a sketch
of the desired output structure expressed in terms of the input
structure. Basically, this is what I'm asking for, but FORMAL is
limited to hierarchical databases. This work reminded me of Query
By Example except that the output may be a (hierarchical) database
structure and not just a list of tuples satisfying the sketched
conditions. FORMAL is described in "Automatic Data Transformation
and Restructuring," by Nan C. Shu, Proc. 3rd Intl. Conf. on Data
Engr., 1987.
3. Stage, a system for generating application generators by J. Craig
Cleaveland. The application generators Stage generates are, in
effect, data transformation systems. The input to Stage is (a) a
grammar describing the input to the desired application and (b) a
sketch-like description of the desired output of the application
expressed in terms of the parse tree of the input. Stage then
generates a program to perform such transformations. Stage is
described in a forthcoming article "Building Application
Generators," in IEEE Software, July, 1988.
It is clear that the problem as posed it is not well formed. That is, any
program could be described as a data structure transformer, so asking for a
system in which to describe more or less arbitrary transformations is asking
for too much.
One approach would be to limit the problem to a system for describing
transformations that operate on the structure of the data and that are not
dependent on the content. That is not satisfactory for a couple of reasons.
- For one thing the Teamwork/P-Nut example given above does not fit
this description since the content of the data structure must be
examined at least to the extent of determining concurrency and
process sequencing.
- Even worse, since a two counter machine is Turing equivalent, a
system that deals generally with a pair of lists whose lengths (but
not content) matter is equivalent to a general purpose programming
language.
All that notwithstanding, there does seem to be some value in developing a
notation in which data structures and transformations on them can be
described--and then automatically implemented. In addition, it seems that
prolog would be a suitable language in which to develop such a system.
As an experiment, a program has been written in C-Prolog that transforms data
transformation descriptions into corresponding data transformation programs.
The input to be transformed is assumed to be given as a set. For this example,
each set element is a pair, where the first component is a set of positive and
negative conditions and the second is a set of processes and their execution
levels. The input is stored on the file teamwork_to_pnut.
[c1/(+), c4/(-)], [p2/1, p4/1, p5/2].
[c1/(+), c2/(+), c3/(-)], [p1/1, p1/3, p2/2, p3/1, p3/3, p4/4, p5/4].
These are intended to correspond to the two rows of the process activation
table.
In specifying the output, the transformation description (see below) includes
new symbols: start(Process) and finish(Process), corresponding to Ps and Pf,
for each Process P; and row(<Conditions>, <Level>) for each row and level. The
actual (although manually formatted) output produced by the generated program
is as follows.
Output =
/* The processes */
start(p1) -> finish(p1)
start(p2) -> finish(p2)
start(p3) -> finish(p3)
start(p4) -> finish(p4)
start(p5) -> finish(p5)
/* The first row */
[c1, c2, not c3] -> [start(p1), start(p3), row([c1, c2, not c3], 1)]
[finish(p1), finish(p3), row([c1, c2, not c3], 1)] ->
[start(p2), row([c1, c2, not c3], 2)]
[finish(p2), row([c1, c2, not c3], 2)] ->
[start(p1), start(p3), row([c1, c2, not c3], 3)]
[finish(p1), finish(p3), row([c1, c2, not c3], 3)] ->
[start(p4), start(p5), row([c1, c2, not c3], 4)]
[finish(p4), finish(p5), row([c1, c2, not c3], 4)] -> []
/* The second row */
[c1, not c4] -> [start(p2), start(p4), row([c1, not c4], 1)]
[finish(p2), finish(p4), row([c1, not c4], 1)] ->
[start(p5), row([c1, not c4], 2)]
[finish(p5), row([c1, not c4], 2)] -> []
Here is the actual data transformaton specification. The input file and its
structure is specified as follows.
input = file teamwork_to_pnut.
structure row = (conditions, processes).
The output is also described as a set--the set of Petri net transformations.
Four different kinds of transformations are generated. Letting + stand for set
union:
output(Input) = output1(Input) + output2(Input) +
output3(Input) + output4(Input).
The individual transformations may be described as follows.
1. Each row has a unique starting Petri Net transition. Its LHS is the
set of conditions that characterize the row. Its RHS is the set of
processes at level 1.
output1(Input) =
{conditions(Row) -> rhs(Row, 1) | Row in Input}.
where
conditions(Row) = pos_conds(Row.conditions) +
neg_conds(Row.conditions).
pos_conds(Conditions) =
{Condition | Condition/(+) in Conditions}.
neg_conds(Conditions) =
{not Condition | Condition/(-) in Conditions}.
rhs(Row, Level) =
{start(Process) | Process/Level in Row.processes} +
{row(conditions(Row), Level)}.
2. The second kind of transformation appears once for each Process.
Each Process has an associated transformation from its start to its
finish.
output2(Input) =
{start(Process) -> finish(Process) |
Row in Input,
Process/_ in Row.processes}.
where
lhs(Row, Level) =
{finish(Process) | Process/Level in Row.processes} +
{row(conditions(Row), Level)}.
3. The third kind of transformation links the termination of Processes
at one level to the start of Processes at the next level.
output3(Input) =
{lhs(Row, Level) -> rhs(Row, Level+1) |
Row in Input,
_/Level in Row.processes,
_/(Level+1) in Row.processes}.
4. The fourth kind of transformation terminates the processing of the
rows. There is one for each row.
output4(Input) =
{lhs(Row, Level) -> [] | Row in Input,
_/Level in Row.processes,
_/(Level+1) not in Row.processes}.
The preceding does the required transformations, but it has limitations.
- The transformations are done abstractly. In practice, the concrete
representations of the input and output must be dealt with also.
- The generated program is not optimized.
- In this example, sets suffice. For some other problem some data
structure other than sets may be required. But since any data
structure can be mapped onto relations, perhaps this is all we need.
All in all, it doesn't seem like a bad start. My question is whether anyone
knows of existing work along these or similar lines?
Thanks,
-- Russ Abbott
------------------------------
Date: 26 May 88 19:18:06 GMT
From: ulysses!terminus!rolls!mtuxo!mtfmi!dbrod@ucbvax.Berkeley.EDU (D.BRODERICK)
Subject: screen control
If your version of Prolog does not have screen control predicates,
but you are familiar with the Unix(tm) tput(1) command
(or willing to become so), there is a quick and dirty way to
generate some character based screen control predicates.
tput(1) makes use of the terminfo database to generate terminal
specific escape sequences to control the screen. For example,
the following, invoked from the shell, will print out "hello"
in standout mode:
tput smso; echo hello; tput rmso
As you can see, the argument names are intuitively obvious(?).
To use this information from Prolog, write a shell script
called "get_tput" as follows:
--------------------------------------
echo "tput('$2',$1,'`tput -T$1 $2`')."
--------------------------------------
This is invoked, for example, as:
get_tput vt100 clear >> tput.pl
It is easy enough to use a for-loop to generate a prolog
terminfo database for all the tput arguments/terminals you want.
For an interesting sight, cat the file. ("tput sgr0" sets to normal)
To use on a PC running an ansi.sys driver, generate a database
for ansi and download.
To use:
consult('tput.pl'). and call
tput(clear). , defined as:
tput(Cmd) :- tput(Cmd,_,EscSeq), atomic(EscSeq), write(EscSeq).
tput(Cmd) :- tput(Cmd,_,[Esc|Seq]), print_list([Esc|Seq]).
tput(Cmd) :- not tput(Cmd,_,_).
This assumes you have loaded info only for your current terminal.
The reason for the middle clause is that shell tput commands that
take more than one parameter return a sequence that needs further
parsing. I have not written a general parser, but have done some
of these by hand. In what follows, what looks like ↑ followed by [
is actually a real Escape char (in case you retype this).
% cup - set cursor position. this works for vt100 and ansi
tput(cup(Row,Col),att5425,['[',R1,';',C1,'H']) :- R1 is Row+1, C1 is Col+1.
% csr - change scroll region
tput(csr(Top,Bottom),att5425,['[',T1,';',B1,r]) :-
T1 is Top+1, B1 is Bottom+1.
% pln - set system function key Not on many terminals
tput(pln(Key,Label,Command),att5425,
['[',Key,';',Len,';0;0q',Label16,Command]) :-
name(Command,CAscii),
length(CAscii,Len),
pad_atom(16,Label,Label16).
tput(user,att5425,'}'). % switch to user function keys
tput(system,att5425,'~'). % switch to system function keys
% tsl - write to status line
tput(tsl(Col),att5425,['7[25;',Col1,'H']) :- Col1 is Col + 8.
% auxiliary predicates
print_list([]).
print_list([X|Xs]) :- write(X), print_list(Xs).
pad_atom(Num,Atom,Padded) :-
name(Atom,AAscii),
length(AAscii,Len),
Pads is Num - Len,
pad_blanks(Pads,BString),
append(AAscii,BString,PAscii),
name(Padded,PAscii).
pad_blanks(0,[]).
pad_blanks(Num,[32|Blanks]) :-
Num > 0,
Num1 is Num-1,
pad_blanks(Num1,Blanks).
% append/3 as usual
------------------------------
Date: 29 May 88 04:25:44 GMT
From: quintus!ok@sun.com (Richard A. O'Keefe)
Subject: Screen Control
In article <701@mtfmi.UUCP>, dbrod@mtfmi.UUCP (D.BRODERICK) writes:
> If your version of Prolog does not have screen control predicates,
> but you are familiar with the Unix(tm) tput(1) command
It's worth pointing out that
(a) tput is a System V feature, not present in most BSDs (but SunOS has it).
(b) There are some non-trivial differences between V.2 tput and V.3 tput
(as I found the hard way when some scripts I wrote on a V.3 system
didn't work on a V.2 system.)
(c) Some of the things tput returns are numbers, for example
tput lines
prints the number of lines on the screen. Suppose that is 24.
The "get_tput" script provided by D.BRODERICK will write this as '24',
which is an atom. You may want to have another script which writes
things unquoted so that you can access such terminal properties.
(d) Some of the things tput reports are "boolean", for example
tput hc # is it a hard-copy terminal?
always prints nothing. Instead the answer is to be found in the exit
code (0 means yes, non-zero means no). You may want a third script
if tput -T$1 $2 ; then
echo "tput($2, '$1', true)."
else
echo "tput($2, '$1', false)."
fi
for use with boolean capabilities.
(e) tput writes things out verbatim, without escape characters. Some
Prolog systems may discard CRs or do other odd things with strange
characters. (Quintus Prolog is safe, but watch out for terminal
capabilities containing apostrophes.)
If the Prolog dialect you are using has an interface to C (as many have)
you would be better off writing an interface to 'curses'; since 'curses'
is available for IBM PCs and VAX/VMS as well as for UNIX this may be more
portable than using tput. In particular, if you use curses, you don't
have to figure out how to parse the 'cup' capability (rather hairy).
Then too, I for one would rather hide the rather bizarre capability
names (quickly now: what does eslok do?) from my Prolog code.
------------------------------
End of PROLOG Digest
∂16-Jul-88 0137 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #44
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Jul 88 01:37:50 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA25898; Mon, 11 Jul 88 11:37:06 PDT
Date: Mon, 11 Jul 88 11:37:06 PDT
From: Chuck Restivo <restivo@polya.Stanford.EDU>
Message-Id: <8807111837.AA25898@polya.Stanford.EDU>
To: restivo@polya.Stanford.EDU
Subject: PROLOG DIGEST V6 #44
Date: Mon, 11 Jul 1988 02:53-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@POLYA.STANFORD.EDU>
Reply-to: PROLOG@POLYA.STANFORD.EDU>
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #44
To: PROLOG@POLYA.STANFORD.EDU
PROLOG Digest Monday, 11 July 1988 Volume 6 : Issue 44
Today's Topics:
Query - dBase III,
Implementation - VAX/VMS Review
------------------------------------------------------------------------------------------------------------------------------
Date: 24 Jun 88 18:29:32 GMT
From: uccba!ucqais!bbeck@tut.cis.ohio-state.edu (Bryan Beck)
Subject: Query Dbase III Plus with Turbo Prolog
I recently read an article in AI EXPERT, June 1988 written by Karl Horak about
using Turbo Prolog to query Dbase III Plus files. There were two points that
were not clearly delineated in the article, (1) How to get prolog to read the .dbf and
how to get prolog to read the .dbt files.
Also the article referencing Fileman, Rick. "Memo to Character Conversion,"
Aston-Tate Inc. TechNotes, Nov. 1987,pp 15-24.
I any one has read this article of have done anything like this, or where I can find these TechNotes. I would greatly appreciate any additional information
about trying to do this.
Thank you.
------------------------------
Date: 29 Jun 88 14:37:22 GMT
From: mcvax!ukc!dcl-cs!simon@uunet.uu.net (Simon Brooke)
Subject: Survey of Prologs for VMS VAX
About 10 days ago, I put out a message asking people to recommend PROLOGs
for VAX VMS. Many thanks to all those who replied. I'm posting (in case
anyone else is interested) what I learned. Brief word of explanation: I
was asked to select a PROLOG in which it would be possible to construct an
interface to a relational database mangement system, and the report is
heavily biased to reflect this need.
PROLOGs available for VAX/VMS:
A brief review, with regard to the needs of the Savant
project.
How systems were selected for inclusion into this report
In order to find as many VMS compatible PROLOGs as
possible, in the shortest possible time, I posted to the
USENET newsgroup comp.lang.prolog, on the basis that all
serious PROLOG developers would inevitably keep an eye on
this. This method appears to have was only partially
partially successful, in that it produced reviews of most
of the systems I was already aware of, including systems I
wasn't aware were available for VMS. However, it didn't
produce any news of systems I don't know about, and there
may still be some of those.
I also consulted the news section of the Journal 'Expert
Systems', going back two years.
What I asked for
The message which I posted asked respondents to tell me:
* What syntax it uses - especially, how like Quintus it is.
* What the 'foreign function interface' is like.
* Roughly what the performance is like.
* What the programmer's environment is like . . .
* How robust it is - and any points to watch...
* What it costs and from whom (UK supplier if possible)
The systems included
The systems which I received replies about were as follows
(in the order I received them):
Edinburgh Prolog
Quintus Prolog (two replies)
BIM_Prolog (two replies)
Poplog
On the whole, replies were directly from implementors, and,
although they may be somewhat more honest than promotional
literature, cannot be considered independent.
I also have received promotional material describing
LPA Sigma Prolog
and have found a news item describing
I/F Prolog.
Experience of the systems
I have been able to play with Quintus (on Suns under Unix),
Edinburgh (on VAX under Unix), and Poplog (on Suns under
Unix).
Quintus
This is the only one of the systems I have any significant
experience with. Quintus is a widely used - and in general
widely liked - version of a vanilla flavoured Edinburgh-
syntax PROLOG. After LISP machines, the EMACS based
development environment strikes me as so wretchedly crude
as to be almost unusable. However, by using system editors,
code can be developed reasonably quickly.
The system is relatively fast, and appears well thought out
and solid. I imagine that, on a Xerox workstation, this is
a very nice system.
Edinburgh
I have played only briefly with Edinburgh Prolog. I loaded
in the dBAccess code, most of which ran. However, the use
of the token 'not' as a negation operator is apparently not
permissible in Edinburgh prolog, and, as I did not have a
manual, I was unable to attempt to patch this.
There appears to be no compiler.
My feeling, however, is that it would be trivial to port to
Edinburgh Prolog. Whether any particular development
environment tools are supplied I can't say; but if not,
they aren't strictly needed.
Poplog
Again, I have experimented only briefly with Poplog. My
first impression was of quite remarkable slowness. Whilst
the reader of the Edinburgh system skipped over the
declarations in the (Quintus) files containing the dBAccess
code which it could not understand (because they were
Quintus specific), the Poplog reader aborted. Thus these
files could not be loaded without some editing.
Again, the syntax of 'not' differed from Quintus; in Poplog
prolog, 'not' is a one place predicate rather than a prefix
operator.
Once the files had been edited, they loaded satisfactorily,
and again, very nearly ran. Again, there appeared to be no
compiler.
Discussion
Relative performance
I don't have any good comparative figures on the relative
performance of these systems. However, what I have is as
follows:
Version KLips Hardware KLips Test Syntax Price
/Mips
Edin 2.2 VAX 750/Unix 3.66 N.Rev Edinburgh #1000
BIM 26 VAX 750/VMS 43.33 N.Rev proprietary #8150
85 Sun 3 42.5 ?? [Edin optional]
Sigma 6.9 Sun 3 3.45 ?? Lisp-based #750 [one user]
[Edin optional]
Quintus 60 Sun 3 30 N.Rev Edinburgh #4200
I/F 90 Sun 3 45 ?? Unknown #11000
40 VAX 780 ?? ??
Poplog 4.5 VAX 750 7.5 ?? Edinburgh #12000
As the Sun is rated at about 2 Mips, and the VAX 750 at
0.6 Mips, this suggests that I/F may be fastest of all,
with LPA Sigma slowest; the column KLips/Mips uses this
estimation to try to produce a normalised speed for each
implementation. Also, these figures come from various
different sources, and reflect different peoples
benchmarks; they may not be directly comparable.
Nevertheless, the fastest PROLOGs are clearly very much
faster than the slowest. This at least partly reflects the
fact that some of these systems are interpreters only,
while some have compilers. Certainly Sigma has no compiler,
and I was unable to find one in either the Edinburgh or
Poplog systems. Given the benchmark speeds quoted, I would
suspect that none of these systems has a compiler, while I
know that all the others do.
Prices and where possible speeds have been verified with UK
suppliers.
Foreign Function Interface
All the systems described with the exception of I/F (about
interfaces to C. Specific claims are as follows:
Edinburgh
"Users can supply C bodies for Prolog predicates - this is
easy under UNIX, as the .o file can be dynamically loaded,
but we are just now doing the decomposition to let the
object file be linked into the executable under VMS (pardon
any terminology errors, VMS isn't my own field)" (source:
Correspondence with implementor)
BIM:
"BIM_Prolog has a complete interface to all procedural
languages which create a standard VAX/VMS object file.
Examples of C and Fortran are delivered with the
distribution" (source: Correspondence from BIM
representative)
"BIM_Prolog has an external language interface, although it
has no dynamic linking: it means that you can link into the
system a package (or more than one) with C functions - or
assembler, pascal, ada ... as long as the linker of VMS can
link the object of BIM_Prolog to it" (source:
correspondence with user)
LPA Sigma:
"A simple to use 'C' language interface allows new
facilities to be added quickly to the basic system"
(source: promotional literature).
Quintus:
The UNIX version of Quintus provides interfaces to C,
Pascal, and Fortran; I have no information to hand about
the VMS version. (source: User Guide)
I/F: no information
Poplog:
The Poplog environment includes LISP, POP-11, and
optionally ML in addition to Prolog, and all these can be
integrated. Additionally, "....you can link in C, Fortran,
or whatever" (source: correspondence from Prof Aaron
Sloman)
Recommendations
I would not at this stage recommend I/F Prolog, as,
although it's performance is reported to be very good, I
don't have adequate information about it; also, it's price
is extremely high. I would not recommend Sigma, as its
performance is just too poor, and this generally reflects
my experience of LPA implementations - nice systems with
dreadful performance. Also, LPA are no longer supporting
Sigma. They plan to have a new implementation out sometime
next year. Of the remaining systems:
Quintus
Quintus is (I believe) the market leader; it is solid, well
behaved and well supported, reasonably fast and not
excessively priced.
BIM
BIM_Prolog has two primary advantages: firstly it is fast;
secondly, it comes with a complete and working database
interface. Although it is more expensive than Quintus, the
benefits of a supplier supported db interface might well
more than make up for this from Savant's point of view (of
course, it would also put me out of a job).
Poplog
Is a very rich environment - far richer than is needed for
the current project. Although a nice product, it is less
suitable for our purposes than BIM, in view of its greatly
inferior speed, and lack of database interface.
Edinburgh
Is adequate for development purposes, and is very cheap.
The project would probably have to buy a faster system when
the time came to construct a marketable product.
Conclusion
Edinburgh PROLOG, plus my salary for as long as it takes to
make Edinburgh do what BIM already does, would probably add
up to a fair proportion of the cost of BIM - for a system
with markedly inferior performance.
So I (were I not me) would buy BIM (I'd want to see it first) - unless a
proprietary database interface is of primary importance; in
which case Edinburgh would do only as a cheap development
system, with Quintus being required for serious product
development.
-- Simon Brooke
--------------------------------
End of PROLOG Digest
∂16-Jul-88 2354 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu French-Israeli Symposium on Combinatorics and Algorithms
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Jul 88 23:54:10 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA10168; Sat, 16 Jul 88 23:53:37 PDT
Message-Id: <8807170653.AA10168@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Sat, 16 Jul 88 23:53:55 PDT
Received: by Forsythe.Stanford.EDU; Sat, 16 Jul 88 23:55:30 PDT
Received: by BYUADMIN (Mailer X1.25) id 9052; Sun, 17 Jul 88 00:46:42 MDT
Date: Sat, 16 Jul 88 22:07:14 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Marty Golumbic <GOLUMBIC%ISRAEARN.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Marty Golumbic <GOLUMBIC%ISRAEARN.BITNET@forsythe.stanford.edu>
Subject: French-Israeli Symposium on Combinatorics and Algorithms
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
------------------------------------------------------------------------------
Please Post
Binational French-Israel Symposium
on
COMBINATORICS AND ALGORITHMS
Second Announcement
Jerusalem -- November 13-17, 1988
The Ministry of Science and Development would like to announce the
upcoming joint French-Israeli Symposium on the above mentioned subject,
organized in the framework of scientific and cultural agreements existing
between the two governments. The four-day symposium will be held at the
Academy for Sciences and Humanities in Jerusalem, Israel.
The symposium is sponsored by the Department for Science and Technology
of the French Ministry for Foreign Affairs, the Maurice and Gabriela
Goldschleger Conference Foundation at the Weizmann Institute of Science,
Tel Aviv University, the Hebrew University of Jerusalem, and the Israel
Mathematical Union.
Abstracts of about 200 words, typed on a single quarto paper, suitable
for photographic reproduction, are to be sent by July 15, 1988 to
C. Weintraub, Dept. of Applied Math. & Computer Science, Weizmann
Institute of Science, Rehovot, Israel; maweintr@weizmann.bitnet
Proceedings of refereed full-length papers will appear. The papers are
due at the Conference.
Those who wish to be assisted in hotel accomodation can use our
special rates at the Moriah Hotel, Jerusalem. The rates are about
$33 per person in shared accomodation (Bed and Breakfast). An additional
$17 per day in a single room (Bed and Breakfast). Please inform us if
you require hotel reservation so we can arrange it for you by the
end of July 1988.
Participation at the Conference is limited by the capacity of lecture
rooms. There will be no registration fees. Lunches and coffee breaks
during the conference will be provided by the Organizing Committee.
Participants are expected to arrive on Sunday, Nov 13. A get-together
is planned at the Moriah Hotel in the evening. Technical sessions begin
on Monday morning, Nov. 14.
A first list of participants includes: R. Aharoni, N. Alon, A. Barlotti,
A. Berman, J.-C. Bermond, J. Bond, A. Bouchet, R. Cori, M. M. Deza,
A.S. Fraenkel, P. Frankl, G. Giraud, M.C. Golumbic, R.L. Graham,
P.L. Hammer, A. Hartman, P. Hell, R. Holzman, W. Imrich, M. Kachalski,
G. Kalai, D.J. Kleitman, E. Korach, B. Korte, M. Las Vergnas, M. Laurent,
L. Lovasz, M. Perles, J. Schoenheim, A. Shamir, E. Shamir,
M. Simonovits, V. Sos, D. Sotteau, J. Spencer, A. Wigderson.
Other distinguished guests are invited including Prof. P. Erdos.
Address for registration and further information:
Mrs. Shulamith Cahana
Dr. Gideon Ariely
Ministry of Science and Development
P.O.B. 18195
Jerusalem, Israel
E-mail: gideon@ilncrd.bitnet
Fax: 02-820591
Name and Title.....................................................
Affiliation........................................................
Address............................................................
...................................................................
...................................................................
Telephone................... Telex...............................
Fax......................... Bitnet..............................
___ I would like to attend the conference
___ I expect to be accompanied by ___ non-participant/s
∂17-Jul-88 0518 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #47
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jul 88 05:18:43 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA13201; Sun, 17 Jul 88 04:08:27 PDT
Date: Sun, 17 Jul 88 04:08:27 PDT
From: Chuck Restivo <restivo@polya.Stanford.EDU>
Message-Id: <8807171108.AA13201@polya.Stanford.EDU>
To: restivo@polya.Stanford.EDU
Subject: PROLOG DIGEST V6 #47
Date: Sun, 17 July 1988 02:53-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@POLYA.STANFORD.EDU>
Reply-to: PROLOG@POLYA.STANFORD.EDU>
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #47
To: PROLOG@POLYA.STANFORD.EDU
PROLOG Digest Sunday, 17 July 1988 Volume 6 : Issue 47
Today's Topics:
Announcement - Lambda 2.7,
Query - Control & Unification,
Implementation - BFE
-----------------------------------------------------------------------------------------------------------------------------
Date: 11 Jul 88 21:03:34 GMT
From: aurak!gopalan@cs.duke.edu (Gopalan Nadathur)
Subject: lambda version 2.7
This is just to inform people of the availability of Version 2.7 of
lambda Prolog. Lambda Prolog is a logic programming language that is
based on the logic of higher-order hereditrary Harrop formulas, a rich
extension to the logic of first-order Horn clauses. The use of this
extended logic provides lambda Prolog with a logically justified
treatment of higher-order functions and modular programming.
Higher-order features are implemented using higher-order unification
and lambda-conversion, both of which are primitive operations in the
language. This language has several application areas, some of these
being program transformation and development systems, tactical-style
theorem provers, type inference programs, and natural language
processing. Several aspects of lambda Prolog and its applications are
discussed in papers that appear in the proceedings of the following
conferences:
International Conference on Logic Programing 86,
Symposium on Logic Programming 86, 87, 88
Logic in Computer Science 87
Conference on Automated Deduction 88
Detailed references to the published and submitted papers on lambda
Prolog are included with the material being distributed.
Version 2.7 of lambda Prolog modifies Version 2.6 that has been in
distribution since August 1987. The main changes are the fixing of a
few bugs that have been pointed out to us over the last year, the
addition of a few new features and the availability of the source code
for bringing up the system under Quintus. The material that
constitutes this version may be obtained via anonymous ftp from Duke
University by executing the following steps:
(1) ftp to duke.cs.duke.edu
(2) log in as anonymous. Use your own login id as the password.
(3) cd to pub and retrieve the file lp2.7.tar.Z
(5) quit ftp and cd to whichever directory you wish to bring
up lp2.7 in. Then execute the following commands
uncompress lp2.7.tar.Z
tar xf lp2.7.tar
At the end of this process you will have a directory called lp2.7
that should contain the following subdirectories
72 lp2.7/doc
173 lp2.7/src
180 lp2.7/src-quintus
8 lp2.7/sysmods
29 lp2.7/examples/cade9
32 lp2.7/examples/meta88
17 lp2.7/examples/acl86
22 lp2.7/examples/slp87
16 lp2.7/examples/misc
21 lp2.7/examples/typeinf
12 lp2.7/examples/metainterp
150 lp2.7/examples
There will be a README file in lp2.7 and lp2.7/doc/install will contain
notes describing the procedure for installing lambda Prolog within C-Prolog
(Version 1.5) and Quintus Prolog (Version 2.0).
If you encounter any problems getting this files or in installing the
system, please let me or Dale Miller (dale@linc.cis.upenn.edu) know.
Bug reports are also welcome, although there is no guarantee that they
will be fixed! If you obtain a copy of the system and let Dale and me know,
we will keep you posted about updates to the code.
-- Gopalan Nadathur
----------------------------
Date: 13 Jul 88 18:10:44 GMT
From: zodiac!MERIDIAN.ADS.COM!marcel@ames.arc.nasa.gov (Marcel Schoppers)
Subject: tidying up control
I haven't kept up with attempts to clean up search control in Prolog, but
let me throw out an idea and see what happens.
Control in Prolog, when used around single predicates, comes in a few common
flavors:
0 let P be satisfied any number of times with backtracking
(no control)
1 let P be satisfied exactly once and report an error if it
can't be satisfied (e.g. many built-ins and "low-level"
user-defined procedures)
2 let P be satisfied zero times (not P)
and very occasionally one needs
3 let P be satisfied at most once
4 see if P is satisfiable but don't bind any variables
There is a fairly simple and neat way of capturing all these options with the
following four operators:
[ P P has >=1 solutions -- normal case ]
-P P has 0 solutions (don't bind vars, no backtracking)
+P P has >=1 solutions (don't bind vars, no backtracking)
@X print error and fail unless X <one of the above>
X! allow only 1 solution for X
These operators combine to give the following control options:
-P fail if there are any Ps (= not), don't bind vars, succeed once
+P fail if there are no Ps, don't bind vars, succeed once
@-P print error & fail if there are any Ps, don't bind vars, succeed once
@+P print error & fail if there are no Ps, don't bind vars, succeed once
P fail if there are no Ps, do bind vars, succeed N times
@P print error & fail if there are no Ps, do bind vars, succeed N times
P! fail if there are no Ps, do bind vars, succeed once
@P! print error & fail if there are no Ps, do bind vars, succeed once
So, with only four operators and at most two per term, we get the full range
of ways to control how a goal can be satisfied. These are almost enough to
replace the cut, but not quite. There are two types of control situations that
these operators can't handle. Once of them is
pred :- !, fail.
and the other is when we exploit lexical clause ordering, as in
call( (P,Q) ) :- !, call(P), call(Q).
call( X ) :- ... % now can ignore the (P,Q) possibility
In both these cases the cut controls not an individual goal, but affects
the interpretation of the entire set of related clauses (naughty naughty).
I'd like to hear why cut was designed as it was, given that yes, there is only
one cut and it's strong enough to do everything we want, but it's not very
readable and it's also not very intuitive to novices. Is it or is it not a
good idea to replace cut with operators like those I defined above, provided
that the other uses of cut can also be rationalized?
-- Marcel
------------------------------
Date: Tue, 12 Jul 88 08:36:56 EDT
From: spratt%lti.UUCP@bu-it.BU.EDU (Lindsey Spratt x24)
Subject: Unification Algorithm
John Lloyd, in "Foundations of Logic Programming" 2nd extended edition, gives
3 references for linear time/space unification algorithms with the occur check.
I haven't studied any of them, and Lloyd says that none of them are used
in PROLOG systems (surely there must be one somewhere that uses one of these
algorithms). He doesn't say why they aren't used, perhaps the basic
multiplier for their expense is too high, even though they are linear
in complexity.
One of the references is the same as in Ling Kan's original
query. The other two are:
Martelli, A. and U. Montanari, "Unification in Linear Time and Space: A
Structured Presentation", Nota Interna B76-16, Instituto di Elaborazione
della Informazione, Pisa, 1976.
Paterson, M. S. and M. N. Wegman, "Linear Unification", J. Computer and
System Sciences 16, 2 (1978), 158-167.
------------------------------
Date: 11 Jul 88 06:24:15 GMT
From: munnari!mulga!lee@uunet.uu.net (Lee Naish)
Subject: breadth-first evaluation?
In article <1630@kalliope.rice.edu> phil@rice.edu (William LeFebvre) writes:
>I am trying to write a meta-evaluator for a
>specific subset of Prolog programs that does breadth first evaluation
I don't know what your application is, but many people use breadth first
evaluation when they just need any fair search strategy (I know I have).
As a general rule, a bounded depth first search with iterative deepening
is *much* better than breadth first. With breadth first, you tend to
have to copy large quantities of data. Typically, for each call, you
must copy all matching clauses and for each clause (even those which
dont match in a simple implementation), you must copy the current
instance of the variables in the top level goal and the entire current
goal (not just a single call). This copying takes lots of time and
memory.
Depth first evaluation does not need to copy goals or variables since it
only works on one branch at a time. It also takes more advantage of
Prolog operations such as backtracking. There are two potential
problems with it. Firstly, the same solution may be returned several
times (one for each iteration). Secondly, it will never fail (it keeps
trying greater depths indefinitely). The following code avoids the
first problem and can be modified to solve the second problem (by using
a side effect).
-- Lee Naish
P.S. I wont claim this does anything sensible
with negation or cut - they need a bit more work.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% bounded depth first iterative deepening search interpreter
% (ie fair search strategy)
% won't work with side effects but other sys preds ok
% returns all solutions to Goal eventually
% avoids duplicating solutions where Prolog wouldn't
fair_solve(Goal) :-
gen_depth(D, Delta),
fair_solve(D, Delta, Goal).
% meta interpreter with depth
% bound (fail if bound gets to 0)
% Doesn't return success unless depth is within Delta of bound
% (to stop multiple answers being returned on successive
% iterations with increasing depth)
%
% Should really have goal in first argument for indexing
% (NU-Prolog will index on third arg due to when declaration).
?- fair_solve(_, _, G) when G.
fair_solve(D, Delta, true) :-
!,
D < Delta.
fair_solve(D, Delta, (A, B)) :-
!,
fair_solve(D, Delta, A),
fair_solve(D, Delta, B).
fair_solve(D, Delta, (A ; B)) :-
!,
( fair_solve(D, Delta, A)
;
fair_solve(D, Delta, B)
).
% should do more system preds explicitly
fair_solve(D, Delta, A) :-
systemPredicate(A),
!,
call(A).
fair_solve(D, Delta, A) :-
D > 0,
D1 is D - 1,
clause(A, B),
fair_solve(D1, Delta, B).
% generate increasing depth bounds
% and difference between them
gen_depth(D, Delta) :-
gen_depth(3, 100, D, Delta). % initial depth, big delta
gen_depth(D, Delta, D, Delta).
gen_depth(D0, _, D, Delta) :-
Delta1 is D0 // 2 + 1, % anything > 0 would do
D1 is D0 + Delta1, % next depth
gen_depth(D1, Delta1, D, Delta).
----------------------------------
End Of PROLOG Digest
∂17-Jul-88 0533 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #48
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jul 88 05:33:01 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA13750; Sun, 17 Jul 88 04:35:53 PDT
Date: Sun, 17 Jul 88 04:35:53 PDT
From: Chuck Restivo <restivo@polya.Stanford.EDU>
Message-Id: <8807171135.AA13750@polya.Stanford.EDU>
To: restivo@polya.Stanford.EDU
Subject: PROLOG DIGEST V6 #48
Date: Sun 16 July 1988 02:53-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@POLYA.STANFORD.EDU>
Reply-to: PROLOG@POLYA.STANFORD.EDU>
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #48
To: PROLOG@POLYA.STANFORD.EDU
PROLOG Digest Sunday, 17 July 1988 Volume 6 : Issue 48
Today's Topics:
Implementation - Common Subterms
--------------------------------------------------------------------------------------------------------------------------
Date: 12 Jul 88 18:35:31 GMT
From: macbeth!dowding@burdvax.prc.unisys.com (John Dowding)
Subject: Why no macro facility?
In article <9671@lll-winken.llnl.gov> daven@lll-crg.llnl.gov (Dave Nelson) writes:
>Could someone tell me why prolog has no built-in macro facility?
>Even the industrial strength, full-featured prolog I am currently
>evaluating doesn't have such a thing.
I did some experiements with this kind of thing with a parser and found that
it slowed the program down. I think that this is because current Prolog compilers
dont handle very large clauses well. Consider this example:
p(X):-
q(X),
r(X),
s(Y).
q(tree(_,_,_,_)).
If we turn q into a macro, then the resulting clause for p is:
p(tree(A,B,C,D)):-
r(tree(A,B,C,D)),
s(tree(A,B,C,D)).
Note also that where there use to be a single variable X that pointed to the
structure tree/4, now there isnt.
In my application, the use of macros made the size of the resulting clauses enormous.
The resulting program ran as much as 2 times slower than the version with
procedure calls.
-- John Dowding
------------------------------
Date: 13 Jul 88 02:42:21 GMT
From: debray@arizona.edu (Saumya Debray)
Subject: Common Subterms
In article <6899@burdvax.PRC.Unisys.COM>, dowding@macbeth.PRC.Unisys.COM (John Dowding) writes:
> I did some experiements ... and found that it slowed the
> program down. I think that this is because current Prolog compilers
> dont handle very large clauses well. Consider this example:
>
> p(X):- q(X), r(X), s(Y).
> % ↑↑↑ author probably meant s(X) -- skd
> q(tree(_,_,_,_)).
>
> If we turn q into a macro, then the resulting clause for p is:
>
> p(tree(A,B,C,D)):- r(tree(A,B,C,D)), s(tree(A,B,C,D)).
The problem, as the author points out, is that the compiler isn't factoring
common subterms. As a result, multiple copies of the same structure are
being created on the heap. Factoring common subterms in this example would
give
p(X) :- X = tree(_,_,_,_), q(X), s(X).
While common subterm factoring looks very attractive, one problem with
doing it incautiously is that indexing capabilities can be weakened
because a nonvariable term is being pulled from the head into the body
(as in the above example). The resulting choice point creation may well
wipe out any benefits obtained from creating fewer structures on the heap.
Some years back, I looked at incorporating common subterm factoring into
the SB-Prolog compiler. My experience was that people (well, OK,
Prolog hackers who were at Stony Brook at the time) didn't usually
write code with a lot of common subterms to be factored. This, together
with the complications arising from having to make sure that indexing
didn't suffer from such factoring, made the cost of common subterm
factoring unattractive. The current SB-Prolog compiler therefore does
only a limited form of common subterm factoring: the clause
p(f(a,b)) :- q(f(a,b)), r(f(a,b)).
is compiled with three copies of the term f(a,b), but the clause
p(f(g(a))) :- q(h(g(a))), r(f(g(a))).
is compiled as
p(f(X)) :- X = g(a), q(h(X)), r(f(X)).
-- Saumya Debray
------------------------------
Date: 13 Jul 88 11:23:28 GMT
From: kddlab!icot32!icot21!chik@uunet.uu.net (Chikayama Takashi)
Subject: Common Subterms
debray@arizona.edu (Saumya Debray) writes:
> While common subterm factoring looks very attractive, one problem with
> doing it incautiously is that indexing capabilities can be weakened
> because a nonvariable term is being pulled from the head into the body
> (as in the above example). The resulting choice point creation may well
> wipe out any benefits obtained from creating fewer structures on the heap.
I see no reason why the compiler cannot index clauses properly. This
may be true if factoring should be done in the source level BEFORE the
compilation. However, the compiler can be as clever as generating
indexing code based on the original source program and then factorize
common structures when generating each clause.
By the way, the PSI machine has an extended WAM instructions named
"get_structured_constant" and "put_structured_constant". These have
two arguments, an argument register and a pointer to a structure
allocated in the CODE AREA in the compilation (or rather, program
loading) phase. Its spec is similar to "get_value" or "put_value"
except that one of the arguments is a constant structure. The same
applies to the "unify_structured_constant" instruction.
Consider, for example, a predicate such as:
roman(N, R) :-
arg(N, f(i, ii, iii, iv, v, vi, vii, viii, ix, x), R).
Using only the original WAM instructions, it will be compiled to
something like:
put_value A2, A3
put_functor f/10, A2
unify_constant i
unify_constant ii
...
unify_constant x
execute arg/3
which is, at least to me, never acceptable. Of course, the call to
the built-in predicate arg/3 may be compiled out, but I'm not
interested in it here. The "put_structured_constant" instruction can
substitute the put_functor instruction and 10 following unify_constant
instructions. For this specific example, writing the predicate as:
roman(1, i).
roman(2, ii).
...
roman(10, x).
may do almost as good, but the first program looks more compact and
probably more efficient when "put_structured_constant" is used.
Using this, if there are many common structures, the same structure in
the code area can be shared, minimizing the code size. It won't help,
however, when the common structure contains variables.
-- T.Chikayama
------------------------------
Date: 14 Jul 88 07:29:14 GMT
From: mcvax!unido!ecrcvax!micha@uunet.uu.net (Micha Meier)
Subject: Common Subterms
In article <6206@megaron.arizona.edu> debray@arizona.edu (Saumya Debray) writes:
> ... the clause
>
> p(f(g(a))) :- q(h(g(a))), r(f(g(a))).
>
>is compiled as
>
> p(f(X)) :- X = g(a), q(h(X)), r(f(X)).
>--
I have also thought about factoring common terms, however it seems
to me that recognizing them can become *very* costly, especially
when many lists occur in the clause, or do you have some
clever algorithm? On the other hand, it is possible to factor
out even the top-level compound term from the head, you only
have to remember its reference in a variable when the indexed
argument is unified; this, of course, cannot be done using
a source-to-source transformation, it must be done inside
the compiler:
p(f(X)) :- q(f(X)), r(f(X)).
...
switch_on_functor A1, ...
...
get_variable Y1, A1 % so Y = f(X) is part of the head
get_structure f/1, A1
unify_variable Y2
call q/1 % no instruction necessary, anyway
put_value Y1, A1
deallocate
execute r/1
-- Micha
------------------------------
Date: 15 Jul 88 01:32:18 GMT
From: kddlab!icot32!icot21!chik@uunet.uu.net (Chikayama Takashi)
Subject: Common Subterms
In article <561@ecrcvax.UUCP> micha@ecrcvax.UUCP (Micha Meier) writes:
I have also thought about factoring common terms, however it seems
to me that recognizing them can become *very* costly, especially
when many lists occur in the clause, or do you have some
clever algorithm?
The cost is expected to be not much more than linear with the size of
the program. You can compute some hash function for all the
structures occurring in a clause, and register them in a hash table.
On registration, occurrences of the same structure appeared before can
be recognized.
The cost for computing the hash function can be linear with the size
for the lowest level structure. If the hashing function is designed
so that the hash value for upper-level structure only depends on the
hash value of its elements, total cost for computing the hash function
is still linear (you don't have to recompute for elements).
The cost for registration is constant when the same structure is _not_
already in the table, as far as the hash table is not too densely
populated and the hashing function is designed properly to avoid too
many accidental collisions. When the same structure is already there,
matching takes cost proportional to the size of the structure. Thus,
in the worst case, the total cost is proportional to square of the
clause size. However, as this _worst_ case is the _best_ case for
common subterm factoring, it pays off, doesn't it?
If your compiler is written in a language in which efficient hashing
is difficult, such as _standard_ Prolog, it's a thousand pities :-)
-- T.Chikayama
--------------------------------
End Of PROLOG Digest
∂18-Jul-88 1320 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #49
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jul 88 13:19:53 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA07365; Mon, 18 Jul 88 09:34:47 PDT
Date: Mon, 18 Jul 88 09:34:47 PDT
From: Chuck Restivo <restivo@polya.Stanford.EDU>
Message-Id: <8807181634.AA07365@polya.Stanford.EDU>
To: restivo@polya.Stanford.EDU
Subject: PROLOG DIGEST V6 #49
Date: Mon, 18 Jul 1988 02:53-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@POLYA.STANFORD.EDU>
Reply-to: PROLOG@POLYA.STANFORD.EDU>
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #49
To: PROLOG@POLYA.STANFORD.EDU
PROLOG Digest Monday, 18 July 1988 Volume 6 : Issue 49
Today's Topics:
Query - TI -Resolution,
Implementation - Speed & Style,
LP LIbrary - Vision
-----------------------------------------------------------------------------------------------------------------------------
Date: Wed, 13 Jul 88 15:10:21 MDT
From: shauninn@nmsu.CSNET
Subject: TI-Resolution
Does anyone know any references about the work of TI-resolution algorithm
by McSkimin and Minker in early seventies? Please send me a message
if you know any such reference. It will certainly be appreciated!
-- Shaun-inn Wu
------------------------------
Date: 14 Jul 88 23:38:03 GMT
From: debray@arizona.edu (Saumya Debray)
Subject: "A Note on the Speed of Prolog"
The current (August 88) issue of ACM SIGPLAN Notices has an article
"A Note on the Speed of Prolog", by J. Paakki, that's
interesting. The author reports on an experiment comparing the
speeds of compilers, written in Pascal and Prolog, for the
language Edison. What's interesting is that even though the
Prolog implementation used is C-Prolog, the Prolog version of the
compiler is typically only about 5 times slower than the Pascal
version. Now there are faster Prolog systems readily available
that are anywhere from 10 to 50 times faster than C-Prolog.
Assuming that the comparison is a fair one (i.e. noone's
writing execrable Pascal code or using the slowest Pascal system
available), this seems to suggest that using a "state-of-the-art"
Prolog system, one could actually have a Prolog version of the
compiler that was faster than the Pascal version.
-- Saumya Debray
-----------------------------
Date: 15 Jul 88 03:16:19 GMT
From: rochester!daemon@cu-arpa.cs.cornell.edu
Subject: Need style advice
I'd like some advice about how to clean up a relation.
foo_value/2 is intended to be a proper, single-valued, function.
Several clauses can be satisfied at the same time, so I'm depending on
the lexical ordering of clauses and the use of cut to give the proper
precedence among multiple satisfiable clauses and enforce a single
value.
foo_value(X, value_1) :- forced_to_be_1(X), !.
foo_value(X, value_2) :- relation_one(X, Y), not(forced_to_be_1(Y)), !.
foo_value(X, value_2) :- relation_two(X, Y), foo_value(Y, value_2), !.
foo_value(X, value_1) :- relation_one(X, Y), forced_to_be_1(Y), !.
foo_value(X, value_1) :- relation_two(X, Y), foo_value(Y, value_1), !.
foo_value(X, value_3).
Is there a better way to get the same effect? "Better" can mean
more efficient, more aesthetic, closer to purely logical, fewer uses
of cut and not, or whatever metric experienced Prolog users use. :-)
Some other notes:
relation_two/2 contains no cycles. (It is neither reflexive
nor symmetric, nor are there any longer sequences XrY YrZ ... WrX.)
forced_to_be_1/1 is a collection of ground literals.
relation_one/2 and relation_two/2 can satisfy multiple second
arguments for a fully instantiated first argument.
It would be nice, but not essential, if both arguments could be
given as unbound variables. Normally, I try to satisfy
foo_value(literal, V).
-- Stu Friedberg
------------------------------
Date: 15 Jul 88 22:53:51 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Subject: Need style advice
In article <1988Jul14.231619.22145@cs.rochester.edu> stuart writes:
> foo_value(X, value_1) :- forced_to_be_1(X), !.
>
> foo_value(X, value_2) :- relation_one(X, Y), not(forced_to_be_1(Y)), !.
> foo_value(X, value_2) :- relation_two(X, Y), foo_value(Y, value_2), !.
>
> foo_value(X, value_1) :- relation_one(X, Y), forced_to_be_1(Y), !.
> foo_value(X, value_1) :- relation_two(X, Y), foo_value(Y, value_1), !.
>
> foo_value(X, value_3).
> forced_to_be_1/1 is a collection of ground literals.
> relation_two/2 contains no cycles.
> relation_one/2 and relation_two/2 can satisfy multiple second
> arguments for a fully instantiated first argument.
Note that the code as written is not steadfast:
?- foo_value(X, value_3).
will succeed for ANY value of X, even when forced_to_be_1(X).
Remember: a cut at the end of a clause is almost always in the wrong place.
Would it be possible for you to tell us what the relation is supposed to
_mean_, rather than showing us the current version of the code? For
example, the following values for forced_to_be_1/1 and relation_one/2
forced_to_be_1(jim). % "male"
forced_to_be_1(tom).
relation_one(tom, jim). % "sibling"
relation_one(jim, tom).
relation_one(tom, mary).
...
relation_two(_, _) :- fail. % "parent"
appears to satisfy the description given, yet both
relation_one(tom, mary), \+forced_to_be_1(mary)
and relation_one(tom, jim), forced_to_be_1(jim)
are true, so should foo_value(tom, value_2) or foo_value(tom, value_1)?
Presumably there is some finite number of Xs which you intend to assign
foo_values to. If that number is not too big, why not just write a
program to generate the table and write the results to a file, then
compile that file?
------------------------------
Date: 14 Jul 88 06:53:49 GMT
From: ucsbcsl!cornu.ucsb.edu!nosmo@ucbvax.Berkeley.EDU
Subject: summary: Computer Vision and Logic Programming
Well,
Some of you may remember my early posting, regarding the intersection of
computer vision and logic programming. For those of you who replied, many
thanks.
What was found:
Alan J. Vayda (vayda@ee.ecn.purdue.edu) is using prolog for high-level
object recognition on range data. Ref: Kak, Vayda, Cromwell, Kim and Chen,
"Knowledge-Based Robotics", Proc. of the 1987 Conf. on Robotics and Auto-
mation.
Ray Reiter and Alan Mackworth at Univ. of British Colubia have a paper
"The Logic of Depiction" (UBC TR 87-24) which proposes a theory of vision
based in first order logic. Net address: mack%grads.cs.ubc.ca@RELAY.CS.NET.
(note: Dr. Mackworth, I could never get mail back to you. My address is at
the end of this message.)
In vol. 1 of "Concurrent Prolog: collect papers", edited by E. Shapiro, MIT
Press, 1987, S. Edelman and E. Shapiro have "Image Processing in Concurrent
Prolog", this deals with algoritms for low-level vision. (edelman or udi,
@wisdom.BITNET)
Denis Gagne's thesis, from U. of Alberta, in Edmonton, home of the Oilers
and the West Ed. Mall, describes a reasoning approach to scene analysis.
The person that refered this to me didn't know the title, but did give me
a lead on how to find out. Randy Goebel (goebel@alberta.uucp) and David
Poole (dlpoole@waterloo.csnet) were Denis's advisors.
Mulgaonkar, Shapiro and Haralick, describe a rule-based approach for
determining shap-from-perspective in "Shape from Perspective: a Rule Based
Approach", CVG&IP 36, pp. 289-320, 1986.
That's about all that I've heard. I'm still interested in hearing more,
though.
-- Vince Kraemer
∂18-Jul-88 2107 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Divide and Conquer
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jul 88 21:07:36 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA24533; Mon, 18 Jul 88 21:07:05 PDT
Message-Id: <8807190407.AA24533@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Mon, 18 Jul 88 21:07:21 PDT
Received: by Forsythe.Stanford.EDU; Mon, 18 Jul 88 21:08:57 PDT
Received: by BYUADMIN (Mailer X1.25) id 4301; Mon, 18 Jul 88 16:40:59 MDT
Date: Mon, 18 Jul 88 16:48:28 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
cerbone giuseppe <mist!cerbone%CS.ORST.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMZ
From: cerbone giuseppe <mist!cerbone%CS.ORST.EDU@Forsythe.Stanford.EDU>
Subject: Divide and Conquer
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
I would appreciate from the knowledgeable netters references to
the epistemology of various problem solving methods, namely
"Divide and Conquer", backtracking, greedy, etc. In other words
I am interested in knowing where the names come from, who first
proposed them, and so on.
I am also interested in references to formalizations of the vari-
ous methods.
If you are wondering, let me tell you that I have done my home-
work. Yes, I am doing a library search but as you also well
know, the amount of material to look at is large and help is wel-
come. I was able to trace the epistemology question down to ...
Philip of Macedon (382-336 B.C.) whose ruling philosophy is com-
monly described in high school textbooks as : (divide et impera =
divide and rule) (Gee, it pays to learn latin when you are in
high school !!!).
From a computer science standpoint, I think that the closest
works are the ones of Wirth and Dijkstra on stepwise refinement
(early 1970's). In any case I was not able to locate one or more
specific source to reference as THE original one(s).
Please, send e-mail to the address shown below.
I thank everybody in advance.
-- Giuseppe Cerbone
----------------------------------------------------------------------------
--- US-mail --- | --- e-mail ---
Giuseppe CERBONE | Domain: cerbone@cs.orst.edu
OREGON STATE UNIVERSITY | CSNET : cerbone%cs.orst.edu@relay.cs.net
Computer Science Building 100 | UUCP : {hp-pcd, tektronix}!orstcs!cerbone
Corvallis, OR 97331 - 3902 (USA)|
----------------------------------------------------------------------------
∂19-Jul-88 0501 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Urgent: Reply to Cerbone Giuseppe's query
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jul 88 05:01:27 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA04607; Tue, 19 Jul 88 05:00:49 PDT
Message-Id: <8807191200.AA04607@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Tue, 19 Jul 88 05:01:05 PDT
Received: by Forsythe.Stanford.EDU; Tue, 19 Jul 88 05:02:49 PDT
Received: by BYUADMIN (Mailer X1.25) id 9022; Tue, 19 Jul 88 05:52:18 MDT
Date: Tue, 19 Jul 88 06:37:11 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Uri N. Peled" <U32799%UICVM.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: "Uri N. Peled" <U32799%UICVM.BITNET@forsythe.stanford.edu>
Subject: Urgent: Reply to Cerbone Giuseppe's query
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Here is the first reference to "greedy algorithm" in the combinatorial
optimization literature:
Jack Edmonds, Matroids and the greedy algorithm, Mathematical Programming
1(1971) 127-136.
∂19-Jul-88 1154 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #51
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jul 88 11:54:13 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA10723; Tue, 19 Jul 88 09:55:16 PDT
Date: Tue, 19 Jul 88 09:55:16 PDT
From: Chuck Restivo <restivo@polya.Stanford.EDU>
Message-Id: <8807191655.AA10723@polya.Stanford.EDU>
To: restivo@polya.Stanford.EDU
Subject: PROLOG DIGEST V6 #51
Date: Tue 19 Jul 1988 02:53-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@POLYA.STANFORD.EDU>
Reply-to: PROLOG@POLYA.STANFORD.EDU>
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #51
To: PROLOG@POLYA.STANFORD.EDU
PROLOG Digest Tuesday, 19 July 1988 Volume 6 : Issue 51
Today's Topics:
Implementation - Style & Unification
--------------------------------------------------------------------------------------------------------------------------
Date: 17 Jul 88 04:32:41 GMT
From: rochester!daemon@cu-arpa.cs.cornell.edu
Subject: Need style advice
Summary: More information about intended behavior
References: <1988Jul14.231619.22145@cs.rochester.edu>, <170@quintus.UUCP>
> Richard O'Keefe responds to my query with:
> Note that the code as written is not steadfast:
> ?- foo_value(X, value_3).
> will succeed for ANY value of X, even when forced_to_be_1(X).
> Remember: a cut at the end of a clause is almost always in the wrong place.
Ok, that's the first problem. My intent is to use the
value in the head of the first satisfied clause, using value_3 only
when no previous clause can be satisfied.
Your reminder is appreciated, but it would be more useful if I were
also made acquainted with how things *should* be done.
> Would it be possible for you to tell us what the relation is supposed to
> _mean_, rather than showing us the current version of the code?
Yes, my apologies if this description includes irrelevant detail. I
have a graph with two colors of arcs, and two kinds of colors of
nodes. foo_value/2 is to give values to nodes based on graph
connectivity and coloring.
The first kind node color distinguishes between "forced_to_be_1" and
otherwise. If a node is forced_to_be_1, it receives value_1, otherwise
we consider its neighbors. We look, first, for neighbors from whom X
can inherit value_2. If no such neighbors can be found, we look for
neighbors from whom to inherit value_1. If we fond no neighbors from
whom value_2 or value_1 can be inherited, we give X the value_3.
This is what I intended to express through the ordering of clauses.
(1) Is the decision forced, (2) Can we find a value_2, (3) Can
we find a value_1, (4) In all other cases, value_3.
There are two ways for X to inherit a value from a neighbor, and that
is what the pairs of clauses (2&3 and 4&5) were intended to express.
relation_one(X, Y) is satisfied when node X is connected to node Y by
an arc of the first color, and node Y has a particular value of the
second kind of node color. X receives a value based directly on
the first kind of node coloring of Y.
relation_two(X, Y) is satisfied when node X is connected to a node _
by an arc of the first color, and node _ is connected to node Y by
an arc of the second color. (The second kind of node coloring is
irrelevant in this case.) X receives the same value that Y receives.
> For example, the following values for forced_to_be_1/1 and relation_one/2
> [ some clauses deleted ]
> appears to satisfy the description given, yet both
> relation_one(tom, mary), \+forced_to_be_1(mary)
> and relation_one(tom, jim), forced_to_be_1(jim)
> are true, so should foo_value(tom, value_2) or foo_value(tom, value_1)?
foo_value(tom, value_2). My intent is to try the four steps I gave
above, stopping the first time a step succeeds. I suppose I should stress
that I want foo_value to succeed exactly *once* in all cases.
> Presumably there is some finite number of Xs which you intend to assign
> foo_values to. If that number is not too big, why not just write a
> program to generate the table and write the results to a file, then
> compile that file?
Well, if there were only one graph of interest, I'd do that, but this
*is* a (evidently incorrect) program to generate the table! (Actually,
it's my attempt to express more-or-less declaratively what a C program
is busy doing on a dynamically changing graph structure, but you get
the idea.)
****************
Clearly, I have not gone about things the right way. My suspicions
that things could be improved motivated my query in the first place.
I frankly hadn't noticed the "steadfast"ness bug. So, what is the
recommended form for simple decision trees in Prolog? How do I
obtain the intended behavior?
Unless I receive strong urging to the contrary, I would like to *avoid*
rewriting the clause bodies to something like the following:
foo_value(X, a) :- pred_a(X).
foo_value(X, b) :- \+pred_a(X), pred_b(X).
foo_value(X, c) :- \+pred_a(X), \+pred_b(X), pred_c(X).
foo_value(X, d) :- \+pred_a(X), \+pred_b(X), \+pred_c(X).
This is "pure", but I find it harder to read and understand. I suspect
that it's also considerably less efficient. If not so, please urge otherwise.
-------------------------------
Date: Sun, 17 Jul 88 14:33:46 BST
From: Fernando Pereira <pereira%cam.sri.com@ai.sri.com>
Subject: Unification Algorithms
> John Lloyd, in "Foundations of Logic Programming" 2nd extended edition, gives
> 3 references for linear time/space unification algorithms with the
> occur check.
> I haven't studied any of them, and Lloyd says that none of them are used
> in PROLOG systems (surely there must be one somewhere that uses one of these
> algorithms). He doesn't say why they aren't used, perhaps the basic
> multiplier for their expense is too high, even though they are linear
> in complexity.
The reason why most (if not all) Prolog systems do not use any of
these algorithms but rather the Robinson algorithm with the occurs
check removed (RWOC) is not ignorance on the part of the implementers,
but the fact that the algorithms are linear on the _sum_ of the sizes
of the two terms being unified. If this seems modest, consider the
execution of
append([], L, L).
append([X|L1], L2, [X|L3]) :- append(L1, L2, L3).
with the first argument instantiated to a list of length N. If one of
the algorithms in question is being used for all unifications, then
the execution time will be O(N↑2), while it is just O(N) in a normal
Prolog system. In addition to this problem, the cost per basic
unification step in those algorithms is higher than that in the RWOC
algorithm, both because of the more complex data structures used and
the larger amount of information that has to be saved ("trailed") for
backtracking. In the original design of Prolog as a _programming_
_language_ based on Horn-clause logic, it was (correctly) believed
that the potential unsoundness and non-termination caused by the
choice of "unification" algorithm was a lesser evil than using a sound
and always terminating algorithm that made the language unpractical
compared with, say, Lisp -- the obvious counterpart of append/3 in
Lisp is clearly O(N).
Now, it would be nice to have a sound and terminating algorithm and
still maintain the practical efficiency of unification. It would also
be nice to avoid the exponential worst-case performance of the RWOC
algorithm in problems like
exp(N) :- reentrant_term(N,T1), reentrant_term(N,T2), T1 = T2.
reentrant_term(0, 0).
reentrant_term(s(N), f(T,T)) :-
reentrant_term(N, T).
The problem here is that the textually the term corresponds to the
full binary tree of height N, with size O(2↑N), but it only contains
O(N) distinct subterms. Unfortunately, the RWOC algorithm knows
nothing about shared subterms and spends O(2↑N) time unifying T1 with
T2, when O(N) would be sufficient.
The above problems have been attacked in two distinct ways. The first,
more widely available (Prolog-II, SICStus Prolog and probably others),
is based on changing the universe of terms so that the circular
structures created by an algorithm without occurs check are allowed.
This may appear a dirty trick, but in fact work by Colmerauer, van
Emden, Jaffar and others shows that it can be given a reasonable
logical interpretation, in which programs are interpreted not as usual
over the Herbrand universe but rather over a domain of _rational
graphs_, defined by a particular equational theory. However, although
the RWOC algorithm can build such creatures, it may loop if given
them, eg. try
?- X = f(X,X), Y = f(Y, Y), X = Y.
in C-Prolog, Quintus Prolog, and probably most other current Prolog
systems. Instead, what is needed is an algorithm that recognizes when
it is trying to unify a pair of subterms it tried to unify before and
just skip that pair. Various techniques have been proposed for this,
mostly refinements, variations or reinventions of the worst-case
O(N↑2) algorithm presented by Fages in his dissertation. The best
algorithm I know for this purpose is the obvious adaptation of the
UNION-FIND algorithm for FSA equivalence (consult standard textbooks
for this), but it has the problem that a lot of information may have
to be saved for restoring terms on backtracking.
The other alternative is to stick to the usual theory of terms, bring
in the occurs check, but recognize situations in which the full
algorithm is not needed, eg. when unifying the first occurrence of a
variable in the head against the corresponding argument. Ideas of this
nature have been pursued by various people, eg. David Plaisted, but I
don't know of the latest results on its practical application. It
clearly seems a good idea for clausal theorem provers based on Prolog
technology (eg. Stickel's PTTP and Plaisted's prover distributed on
this digest a couple of years ago), but it is unclear to me whether it
is really practical for Prolog execution, eg. whether it will reduce
the execution of append/3 above to O(N).
I apologize to those people who have worked on this problem but were
not mentioned above (I'm composing this without access to a library),
and I would appreciate any corrections, updates and new references on
the topic.
-- Fernando Pereira
--------------------------------
End Of PROLOG Digest
∂19-Jul-88 1429 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Salary Increases
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jul 88 14:29:20 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 19 Jul 88 14:28:27-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA23992; Tue, 19 Jul 88 14:25:18 PDT
Date: Tue, 19 Jul 1988 14:25:16 PDT
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: ac@score
Cc: chandler@polya.Stanford.EDU
Subject: Salary Increases
Message-Id: <CMM.0.87.585350716.chandler@polya.stanford.edu>
Information on salary increases for faculty for the 88-89 academic year is
being distributed. I would like to talk with each of you about your raise
and about how you see your situation in the department. Since schedules
for all of us are complicated in the summer I am going to leave it up to
each of you to arrange with Joyce a time for us to chat.
∂19-Jul-88 1837 mad@polya.Stanford.EDU transitive closure paper
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jul 88 18:37:38 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA04982; Tue, 19 Jul 88 18:34:17 PDT
Date: Tue, 19 Jul 88 18:34:17 PDT
From: Marcia A. Derr <mad@polya.Stanford.EDU>
Message-Id: <8807200134.AA04982@polya.Stanford.EDU>
To: nail@polya.Stanford.EDU
Subject: transitive closure paper
could someone provide me with a copy of the Ramakrishnan and Ioanidis paper
on transitive closure? thanks.
marcia
∂19-Jul-88 2213 @Score.Stanford.EDU:HIRSH@SUMEX-AIM.Stanford.EDU CSD Service Award Nominations
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jul 88 22:12:59 PDT
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 19 Jul 88 22:07:27-PDT
Date: Tue, 19 Jul 88 22:03:54 PDT
From: Haym Hirsh <Hirsh@SUMEX-AIM.Stanford.EDU>
Subject: CSD Service Award Nominations
To: csd-list@score.Stanford.EDU
Message-ID: <12415719451.24.HIRSH@SUMEX-AIM.Stanford.EDU>
Nominations are invited for the fifth Computer Science Department
Service Award. The award is given by the Computer Science Department
at the start of each academic year to recognize outstanding student
contributions to the computer science department, based on the
recommendations of a committee composed of past winners of the award.
Past winners have been Jeff Mogul, Joe Weening, Peter Karp, and Haym
Hirsh.
Please mail your Service Award nominations to Hirsh@Sumex. Please
include a description of the qualifications of the nominee. The
deadline for nominations is Monday, August 8.
Haym Hirsh
Hirsh@Sumex
-------
∂21-Jul-88 1544 MJH-LISPM-mailer Symbolics disk usage
To: MJH-Lispm@SAIL.Stanford.EDU
From: Joe Weening <JSW@SAIL.Stanford.EDU>
Several years ago, the Formal Reasoning project bought a second disk
for the Lisp machine "Ignorant", which we have been using to hold
online sources, documentation, and a lot of user files that wouldn't
fit on the other Lisp machines.
We now have an urgent need for additional disk space on the Alliant
system used by the Qlisp project, and hence I propose to move this
disk from the Lisp machine to the Alliant.
This will cause a certain amount of pain to Lisp machine users, since
the files now residing on Ignorant will have to move to other systems
or be kept offline on tape. I think there is actually enough space
for most of the files, distributed among the other MJH Lisp machines.
If no one has any serious objections, this will happen in a couple of
weeks.
Joe
∂22-Jul-88 1049 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Thermodynamic Depth
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Jul 88 10:49:36 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA03970; Fri, 22 Jul 88 10:48:42 PDT
Message-Id: <8807221748.AA03970@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Fri, 22 Jul 88 07:28:54 PDT
Received: by Forsythe.Stanford.EDU; Fri, 22 Jul 88 07:30:28 PDT
Received: by BYUADMIN (Mailer X1.25) id 8271; Fri, 22 Jul 88 08:26:36 MDT
Date: Fri, 22 Jul 88 09:12:29 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Thearling <steinmetz!vdsvax!thearlin%ITSGW.RPI.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Thearling <steinmetz!vdsvax!thearlin%ITSGW.RPI.EDU@Forsythe.Stanford.EDU>
Subject: Thermodynamic Depth
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Is anyone out there in net.land familiar with the complexity
measure known as "Thermodynamic Depth?" There was a short
piece in the August 1988 Scientific American ("Complexity Counted"
in the Science and the Citizen column) discussing this new measure
of complex systems. According to the article, it was developed by
Seth Lloyd and Heinz Pagels at Rockefeller University (I have never
heard of Rockefeller University - could this in fact be Rochester
University?).
I would appreciate any info that could be provided (especially
any references to published papers).
kurt
-----------------------------------------------------------------------
Kurt Thearling thearlin%vdsvax.tcpip@ge-crd.arpa
General Electric CRD thearlin@vdsvax.steinmetz.ge.com
Bldg. KW, Room C313 uunet!steinmetz!vdsvax!thearlin
P.O. Box 8 thearlin%vdsvax@steinmetx.uucp
Schenectady, NY 12301 kurt%bach@uxc.cso.uiuc.edu
(518) 387-6779 kurt@bach.csg.uiuc.edu
-----------------------------------------------------------------------
∂22-Jul-88 1716 LOGMTC-mailer Martin Davis Talk
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 22 Jul 88 17:15:55 PDT
Received: from russell.stanford.edu by csli.stanford.edu (3.2/4.7); Fri, 22 Jul 88 17:16:01 PDT
Received: from localhost by russell.stanford.edu (3.2/4.7); Fri, 22 Jul 88 17:20:09 PDT
To: logic@russell.stanford.edu
Cc: manevitz@pluto.arc.nasa.gov
Subject: Martin Davis Talk
Date: Fri, 22 Jul 88 17:20:07 PDT
From: Jon Barwise <barwise@russell.stanford.edu>
Talk: Prof. Martin Davis
Department of Computer Science
Courant Institute of Mathematics
NYU
Date: Thursday, August 4
Time: 2 PM
Room: Bldg 244 Rm 209, NASA/Ames
For more info, contact Larry Manevitz, address above in cc.
An abstract and micro-biography of Prof. Davis follows:
FORMAL NOTIONS OF TEST DATA ADEQUACY
Martin Davis
Courant Institute of Mathematical Sciences
New York University
(joint work with Elaine Weyuker)
An adequacy notion represents a criterion for determining that
the testing phase of software development may be ended. This talk will
discuss theoretical models for the notion of adequacy. Adequacy criteria
are seen as serving to distinguish a given program from a certain class of
programs. Different criteria then correspond to different methods for
associating such a class of programs from a given program. In particular,
the class could be (a) the set of programs of SIZE no greater than the
given program, or (b) the class of programs sufficiently NEAR the given
program. These notions are relative to a notion of program size, and
distance between programs, respectively. Certain points, called CRITICAL
are identified, which must belong to every adequate test set. Bounds are
discussed on the number of points in an adequate test set.
MARTIN DAVIS
As undergraduate at City College in New York, studied with Emil
Post. Ph.D. Princeton 1950 under Alonzo Church. Book
"Computability & Unsolvability" 1958, perhaps the first book on
theoretical computer science. Programmed Pressburger procedure on
a johniac 1954. Early work in mechanical theorem proving
(Davis-Putnam procedure). Contributed to solution of Hilbert's
tenth problem. Work on theory of software testing is joint with
Elaine Weyuker. Has been on the faculty of the Courant Institute,
NYU, since 1965, and was one of the charter memebers of the
computer science department (1969). He is professor of
mathematics and computer science, and beginning September 1988,
will be chairman of the computer science department.
- -------
∂25-Jul-88 1152 restivo@polya.Stanford.EDU PROLOG DIGEST V6 #52
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Jul 88 11:52:47 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA12089; Mon, 25 Jul 88 09:17:28 PDT
Date: Mon, 25 Jul 88 09:17:28 PDT
From: Chuck Restivo <restivo@polya.Stanford.EDU>
Message-Id: <8807251617.AA12089@polya.Stanford.EDU>
To: restivo@polya.Stanford.EDU
Subject: PROLOG DIGEST V6 #52
Date: Sat 23 Jul 1988 02:53-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@POLYA.STANFORD.EDU>
Reply-to: PROLOG@POLYA.STANFORD.EDU>
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #52
To: PROLOG@POLYA.STANFORD.EDU
PROLOG Digest Friday, 22 July 1988 Volume 6 : Issue 52
Today's Topics:
Announcement - Career Opportunity,
Implementation - BFS & Performance & Style
--------------------------------------------------------------------------------------------------------------------------
Date: Friday, 22 July 1988 5:01 BST
From: William F. Clocksin <wfc%cam.cl@nss.cs.ucl.ac.uk>
Subject: Lectureship in Artificial Intelligence, Computer Lab., University of Cambridge
There is a vacancy for a University Lecturer in Artificial Intelligence to take up an appointment as soon as possible. Applicants should have a broad knowledge of the field of Artificial Intelligence, and have practical experience in areas such as planning and distributed problem solving. The ideal applicant would work closely with the Laboratory's artificial intelligence researchers, but would complement the Laboratory's existing strengths in natural language processing and computational logic.
The Computer Laboratory has nineteen members of academic staff, some twenty postdoctoral researchers, and eighty research (Ph.D.) students. About 200 undergraduate are taught. The Laboratory has close links with the computing industry, both local and international.
The appointment would be for three years, withthe possibility of reappointment to the retiring age. The pensionable scale of stipends for a University Lecturer, not ordinarily resident in College, is 13,365 (pounds sterling), rising by eleven annual increments to 20,615 (PS).
Further particulars may be obtained from the Secretary of the Appointments Committee, Computer Laboratory, University of Cambridge, Corn Exchange Street, Cambridge CB2 3QG, England, to whom applications, including a curriculum vitae, list of publications, and the names of not more than three referees, should be sent so as to reach him no later than 16 September 1988.
------------------------------
Date: 19 Jul 88 22:23:55 GMT
From: quintus!ok@unix.sri.com
Subject: breadth-first -vs- iterative deepening
Someone recently mentioned that he was writing a breadth-first interpreter
in Prolog, and Lee Naish suggested that iterative deepening might be a
better idea. I'd like to endorse that. I thought it would be interesting
to compare iterative deepening and breadth-first on a toy example. For
the "Advanced Prolog Course" we gave recently at Quintus I wrote a little
package (it's trivial, really it is) that takes rules to be processed by
iterative deepening and turns them into Prolog. So the example is
tree(X+Y) <- tree(X), tree(Y).
tree(a) <- true.
tree(b) <- true.
which expand_term/2 turns into
tree(A+B, N0, N) :- N0 > 0, N1 is N0-1,
tree(A, N1, N2),
tree(B, N2, N).
tree(a, N0, N) :- N0 > 0, N is N0-1.
tree(b, N0, N) :- N0 > 0, N is N0-1.
which is compiled as usual. There is an "interface" routine
id_call/1 which adds the appropriate arguments and generates
an increasing sequence of depth bounds.
For the breadth-first version, I used the obvious interpreter:
% solve(Goal)
% enumerates solutions for Goal in the usual fashion, but finds them
% by breadth-first interpretation of the clauses in rule/3.
solve(Goal) :-
prove([[Goal|[](Goal)]|Tail], Tail, Goal).
prove([Conj|Conjs], Tail, Orig) :-
nonvar(Conj), % don't run off the end!
prove(Conj, Conjs, Tail, Orig).
prove([](Goal), _, _, Goal). % report answer
prove([](_), Conjs, Tail, Orig) :- % look for another answer
prove(Conjs, Tail, Orig).
prove([Goal|Goals], Conjs, Tail, Orig) :-
findall(NewConj, rule(Goal,NewConj,Goals), NewConjs),
append(NewConjs, NewTail, Tail),
prove(Conjs, NewTail, Orig).
with the example clauses written as
rule(tree(X+Y), [tree(X),tree(Y)|Gs], Gs).
rule(tree(a), Gs, Gs).
rule(tree(b), Gs, Gs).
On quite small examples, solve(tree(X)) ran about 75 times slower than
id_call(tree(X)), and this figure worsened fairly rapidly for larger trees.
findall/3 is a library predicate in the version of Quintus Prolog I was
using, so this figure could be improved somewhat, but the fundamental
problem remains: breadth first search has to copy (as in findall/3) the
entire conjunction NewConj in order to rename variables apart, and the
harder the problem, the harder each step becomes.
------------------------------
Date: 19 Jul 88 08:57:25 GMT
From: mcvax!unido!ecrcvax!micha@uunet.uu.net (Micha Meier)
Subject: "A Note on the Speed of Prolog"
In article <6251@megaron.arizona.edu> debray@arizona.edu (Saumya Debray) writes:
>Assuming that the comparison is a fair one (i.e. no one's
>writing execrable Pascal code or using the slowest Pascal system
>available), this seems to suggest that using a "state-of-the-art"
>Prolog system, one could actually have a Prolog version of the
>compiler that was faster than the Pascal version.
Well, I must say that our experiences are different, at least
concerning compilers for Prolog. I'm sure everybody agrees that
Quintus Prolog is a very fast Prolog, but our compiler, written in C,
is about 10 times faster than Quintus compiler written in Prolog
(and it does more optimizations). An interesting thing is that
most of the time is spent in the first pass, i.e. reading in
the clauses; maybe this makes Prolog different from other languages.
-- Micha
------------------------------
Date: 20 Jul 88 16:00:09 GMT
From: debray@arizona.edu (Saumya Debray)
Subject: A Note on the Speed of Prolog
In article <564@ecrcvax.UUCP>, micha@ecrcvax.UUCP (Micha Meier) writes:
> I'm sure everybody agrees that Quintus Prolog is a very fast Prolog,
> but our compiler, written in C, is about 10 times faster than Quintus
> compiler written in Prolog ...
I'm not surprised at that: you'd expect some performance loss in going
from a low-level to a high-level language. A compiler written in
Prolog would have a fair amount of structure copying, runtime type
checking, tagging/untagging of operands, etc., that you wouldn't find
in the corresponding C code. What I found interesting about the
SIGPLAN Notices article I referred to originally was that despite the
overhead of runtime type checking etc., the Prolog code came as close
as it did to the performance of code written in a strongly typed
imperative language.
-- Saumya Debray
------------------------------
Date: 20 Jul 88 01:47:32 GMT
From: quintus!ok@unix.sri.com
I saw (never mind where) the following definition today:
/*1*/ permute(X, [A|Z]) :-
select(A, X, Y),
permute(Y, Z).
permute([], []).
where select/3 is the usual
select(Item, [Item|Set], Set).
select(Item, [OtherItem|Set0], [OtherItem|Set]) :-
select(Item, Set0, Set).
This version of permute/2 looked ugly to me.
(1) From Clocksin & Mellish 1st edition I learned to put base cases
_first_. It is _much_ the clearest place to put them.
(2) It isn't obvious from the code that the induction is really on
the *first* argument of permute/2: if the first argument is unbound
permute/2 may fail to terminate even if the second argument is ground.
A version which has neither of these defects is
/*2*/ permute([], []). % to permute [], return []
permute([X|Xs], Ys1) :- % to permute [X|Xs],
permute(Xs, Ys), % permute Xs giving Ys
select(X, Ys1, Ys). % insert X anywhere in Ys giving Ys1
Now, I think this version is much easier to read.
The reason for the title of this message is that it turns out to be
considerably faster in Quintus Prolog: 4 times faster for tiny lists,
5 times faster for 10 element lists. I can explain the result after
the event, but I wasn't expecting anywhere near that big a difference.
Elegance pays!
Of course, that version still suffers from the well known problem that
it can't be used to solve for the first argument given the second.
But at least it is a bit less surprising that that is so. In fact we
can easily fix that bug and produce a satisfactory permute/2:
/*2*/ permute(Xs, Ys) :-
permute(Xs, Ys, Ys).
permute([], [], []).
permute([X|Xs], Ys1, [_|Zs]) :-
permute(Xs, Ys, Zs),
select(X, Ys1, Ys).
This is a bit less than twice as slow as version /*2*/, but it is
more than twice as fast as version /*1*/ and works both ways around.
[permute(Xs, Ys, Zs) checks that Xs and Zs are the same length, so
that if Ys is known, it will terminate.]
---------------------------------
End of PROLOG Digest
∂26-Jul-88 2250 FEIGENBAUM@SUMEX-AIM.Stanford.EDU [seminars@csl.sri.com (contact lunt@csl.sri.com): David Notkin talk at SRI]
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jul 88 22:50:25 PDT
Date: Tue, 26 Jul 88 22:45:54 PDT
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
Subject: [seminars@csl.sri.com (contact lunt@csl.sri.com): David Notkin talk at SRI]
To: aap@SUMEX-AIM.Stanford.EDU
Message-ID: <12417562105.14.FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
Return-Path: <@Score.Stanford.EDU:seminars@csl.sri.com>
Received: from Score.Stanford.EDU by SUMEX-AIM.Stanford.EDU with TCP; Tue, 26 Jul 88 16:52:54 PDT
Received: from csl.sri.com by SCORE.STANFORD.EDU with TCP; Tue 26 Jul 88 16:14:17-PDT
Received: by csl.sri.com (4.0/4.16b)
id AA00705 for colloq@score.STANFORD.EDU; Tue, 26 Jul 88 16:08:05 PDT
Date: Tue, 26 Jul 88 16:08:05 PDT
From: seminars@csl.sri.com (contact lunt@csl.sri.com)
Message-Id: <8807262308.AA00705@csl.sri.com>
To: csl-seminars@csl.sri.com
Subject: David Notkin talk at SRI
SRI COMPUTER SCIENCE LAB SEMINAR:
THE ORCA PARALLEL PROGRAMMING ENVIRONMENT PROJECT
David Notkin
University of Washington
Computer Science Department
Monday, August 15 at 4:00 pm
SRI International, Conference Room B, Building A
The Orca project at the University of Washington is addressing the problem
of conveniently programming parallel computers to achieve efficient
execution. We are focusing (primarily) on MIMD nonshared memory parallel
architectures such as hypercubes. However, we do not take any given
architecture as a target: rather, we use an abstraction of a parallel
program that can be mapped efficiently on to a broad range of architectures.
In this talk, I will cover three basic topics. First, I will discuss our
evaluation of the Poker parallel programming environment, which is driving
the specification of Orca. Second, I will discuss Voyeur, a component of
Orca that supports graphical debugging and monitoring of parallel programs.
Third, I will discuss some of our initial ideas about the environment
platform that we are designing as a platform on which to build Orca and
other related parallel programming environments.
NOTE FOR VISITORS TO SRI:
Please arrive at least 10 minutes early in order to sign in and
be shown to the conference room.
SRI is located at 333 Ravenswood Avenue in Menlo Park. Visitors
may park in the visitors lot in front of Building A (red brick
building at 333 Ravenswood Ave) or in the conference parking area
at the corner of Ravenswood and Middlefield. The seminar room is in
Building A. Visitors should sign in at the reception desk in the
Building A lobby.
IMPORTANT: Visitors from Communist Bloc countries should make the
necessary arrangements with Liz Luntzel (415) 859-3285 as soon as possible.
UPCOMING SRI COMPUTER SCIENCE LAB SEMINARS:
Monday, August 8: Gio Wiederhold
Tuesday, August 16: Herbert Klaeren
-------
∂27-Jul-88 0813 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Roommate for PODC 88
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Jul 88 08:13:17 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA01307; Wed, 27 Jul 88 06:49:01 PDT
Message-Id: <8807271349.AA01307@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Wed, 27 Jul 88 06:49:12 PDT
Received: by Forsythe.Stanford.EDU; Wed, 27 Jul 88 06:51:03 PDT
Received: by BYUADMIN (Mailer X1.25) id 9086; Wed, 27 Jul 88 07:47:23 MDT
Date: Wed, 27 Jul 88 08:36:09 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Ewan Tempero <ewan%JUNE.CS.WASHINGTON.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Ewan Tempero <ewan%JUNE.CS.WASHINGTON.EDU@Forsythe.Stanford.EDU>
Subject: Roommate for PODC 88
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
I'm looking for a roommate for PODC 88. I have already reserved the room
at the cheap rates.
Thanks,
--ewan
Ewan Tempero. ewan@june.cs.washington.edu
Dept CS, FR-35
Univ. Washington
Seattle WA 98195
∂27-Jul-88 1240 @Score.Stanford.EDU:rw@polya.Stanford.EDU orientation brunch (please?)
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Jul 88 12:39:58 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 27 Jul 88 12:37:12-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA13465; Wed, 27 Jul 88 12:37:44 PDT
Date: Wed, 27 Jul 88 12:37:44 PDT
From: Rich Washington <rw@polya.Stanford.EDU>
Message-Id: <8807271937.AA13465@polya.Stanford.EDU>
To: faculty@polya.Stanford.EDU
Subject: orientation brunch (please?)
I still haven't heard from anyone who is willing to host
the orientation brunch. The people who have hosted it
the past few years are unavailable this year, so we
need someone new to volunteer.
The orientation brunch is scheduled for Sunday, September 25,
although we could move it to Saturday, Sept 24, if it would
be more convenient for you. The brunch is for new students,
student advisors, and faculty -- it is the first department
orientation event. All you need to do is provide space -- we
will provide people to set up and clean up, and we'll take care
of getting the food.
We're in the process of preparing the final orientation mailing,
which is scheduled to go out within a week. In that mailing we
need to tell the new students when and where the brunch will be,
so our situation is getting a bit desperate. If you're willing
to host the brunch, please let us know by sending a note to
rw@polya.
You have our eternal gratitude for volunteering.
CSD Orientation Committee
∂28-Jul-88 1718 SHOHAM@Score.Stanford.EDU laptops
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Jul 88 17:18:19 PDT
Date: Thu 28 Jul 88 17:16:54-PDT
From: Yoav Shoham <SHOHAM@Score.Stanford.EDU>
Subject: laptops
To: ac@Score.Stanford.EDU
Message-ID: <12418026502.10.SHOHAM@Score.Stanford.EDU>
I intend to buy a laptop soon, almost certainly a 386-based one,
possibly the Toshiba 5100. Best quote for a single machine so
far has been $4895, though someone promised to beat it. The price
will drop on a larger order. Does anyone want one?
Yoav
-------
∂28-Jul-88 1758 SHOHAM@Score.Stanford.EDU laptops
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Jul 88 17:58:39 PDT
Date: Thu 28 Jul 88 17:16:54-PDT
From: Yoav Shoham <SHOHAM@Score.Stanford.EDU>
Subject: laptops
To: ac@Score.Stanford.EDU
Message-ID: <12418026502.10.SHOHAM@Score.Stanford.EDU>
I intend to buy a laptop soon, almost certainly a 386-based one,
possibly the Toshiba 5100. Best quote for a single machine so
far has been $4895, though someone promised to beat it. The price
will drop on a larger order. Does anyone want one?
Yoav
-------
∂30-Jul-88 1023 @Score.Stanford.EDU:allison@shasta.stanford.edu Re: laptops
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jul 88 10:23:00 PDT
Received: from shasta.stanford.edu by SCORE.STANFORD.EDU with TCP; Sat 30 Jul 88 10:21:15-PDT
Received: by shasta.stanford.edu; Sat, 30 Jul 88 10:22:39 PDT
Date: Sat, 30 Jul 88 10:22:39 PDT
From: Dennis Allison <allison@shasta.stanford.edu>
Subject: Re: laptops
To: SHOHAM@score.stanford.edu, ac@score.stanford.edu
I might be interested though I was going for the 3100/20. Maybe a
better price could be had even with a combination of units. -dra
∂03-Aug-88 1434 @Score.Stanford.EDU:tajnai@polya.Stanford.EDU Is work being done on "mapping of cognitive load"?
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Aug 88 14:30:14 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 3 Aug 88 14:27:57-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA27489; Wed, 3 Aug 88 14:28:11 PDT
Resent-Message-Id: <8808032128.AA27489@polya.Stanford.EDU>
Return-Path: <tajnai>
Received: by polya.Stanford.EDU (5.59/25-eef) id AA02246; Mon, 1 Aug 88
08:34:44 PDT
Date: Mon, 1 Aug 1988 8:34:42 PDT
From: "Carolyn E. Tajnai" <tajnai@polya.stanford.edu>
To: csd@polya.Stanford.EDU
Cc: tajnai@polya.Stanford.EDU, tajnai@score
Subject: Is work being done on "mapping of cognitive load"?
Message-Id: <CMM.0.87.586452882.tajnai@polya.stanford.edu>
Resent-To: faculty@polya.Stanford.EDU
Resent-Date: Wed, 3 Aug 1988 14:28:07 PDT
Resent-From: "Carolyn E. Tajnai" <tajnai@polya.stanford.edu>
Message-Id: <CMM.0.87.586646887.tajnai@polya.stanford.edu>
I had a call from someone at Unisys asking if we are doing work
on comfpatibility of various tasks -- mapping of cognitive load.
If work is being done in this area at Stanford, please let me know.
If somewhere else, that would be helpful also.
Carolyn
∂03-Aug-88 2153 @Score.Stanford.EDU:HIRSH@SUMEX-AIM.Stanford.EDU nominations deadline reminder -- Monday
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Aug 88 21:41:41 PDT
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 3 Aug 88 21:33:43-PDT
Date: Wed, 3 Aug 88 21:30:28 PDT
From: Haym Hirsh <Hirsh@SUMEX-AIM.Stanford.EDU>
Subject: nominations deadline reminder -- Monday
To: csd-list@score.Stanford.EDU
Message-ID: <12419645525.20.HIRSH@SUMEX-AIM.Stanford.EDU>
The deadline for nominations for the Computer Science Department Service
Award is this coming Monday, August 8. This is your opportunity to speak
up for those you think have made our department a better place. Don't
assume they've already been nominated -- everyone else may be doing the
same!
Send your nominations to Hirsh@Sumex.
Haym
-------
∂04-Aug-88 2033 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu cheap proceedings
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Aug 88 20:33:34 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA02203; Thu, 4 Aug 88 20:32:41 PDT
Message-Id: <8808050332.AA02203@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Thu, 4 Aug 88 16:41:10 PDT
Received: by Forsythe.Stanford.EDU; Thu, 4 Aug 88 16:42:07 PDT
Received: by BYUADMIN (Mailer X1.25) id 9728; Thu, 04 Aug 88 17:38:50 MDT
Date: Thu, 4 Aug 88 13:59:53 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Ian Parberry <ian%PSUVAX1.CS.PSU.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Ian Parberry <ian%PSUVAX1.CS.PSU.EDU@Forsythe.Stanford.EDU>
Subject: cheap proceedings
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Due to some confusion, I find myself with two extra copies of the 1988
STOC proceedings. I am willing (eager) to part with them at the cost price
of $25, a substantial savings over the regular price. I will pay any
(reasonable) postage costs.
-------------------------------------------------------------------------------
Ian Parberry ian@psuvax1.cs.psu.edu ian@psuvax1.BITNET ian@psuvax1.UUCP
Dept of Comp Sci, 333 Whitmore Lab, Penn State Univ, University Park, Pa. 16802
∂05-Aug-88 1004 DELAGI@SUMEX-AIM.Stanford.EDU [delagi%caldec.DEC@decwrl.dec.com (Bruce Delagi): vision processing]
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Aug 88 10:04:13 PDT
Date: Fri, 5 Aug 88 09:56:59 PDT
From: Bruce A. Delagi <DELAGI@SUMEX-AIM.Stanford.EDU>
Subject: [delagi%caldec.DEC@decwrl.dec.com (Bruce Delagi): vision processing]
To: aap@SUMEX-AIM.Stanford.EDU
Message-ID: <12420043569.28.DELAGI@SUMEX-AIM.Stanford.EDU>
for reference.../b
---------------
Return-Path: <delagi%caldec.DEC@decwrl.dec.com>
Received: from decwrl.dec.com by SUMEX-AIM.Stanford.EDU with TCP; Thu, 4 Aug 88 14:52:05 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA01031; Thu, 4 Aug 88 14:55:12 PDT
Message-Id: <8808042155.AA01031@decwrl.dec.com>
From: delagi%caldec.DEC@decwrl.dec.com (Bruce Delagi)
Date: 4 Aug 88 14:25
To: @me@decwrl.dec.com
Subject: vision processing
From: SHARE::TSS "HUDSON ETE 225-5272 04-Aug-1988 0806" 4-AUG-1988 08:33
To: @TSS.DIS,CC
Subj: ETE SEMINAR - PROF. CHARLES WEEMS, 8/24/88, 10:00 AM, HWM CR
Title: "Overview: Image Understanding Architecture"
Speaker: Prof. Charles G. Weems, UMass
Date: Wednesday, August 24, 1988
Time: 10:00 - 12:00 A.M.
Location: Hall of White Mist (HLO1)
Technical Host: Dave Velten, Eng. Mgr.: SEG/AFL
ABSTRACT
This talk will provide an overview of the Image Understanding
Architecture (IUA), a massively parallel, multi-level system
for supporting real-time image understanding applications and
research in knowledge-based computer vision. The design of the
IUA is motivated by considering the architectural requirements
for integrated real-time vision in terms of the type of
processing element, control of processing, and communication
between processing elements.
The IUA integrates parallel processors operating simultaneously
at three levels of computational granularity in a tightly-
coupled architecture. Each level of the IUA is a parallel
processor that is distinctly different from the other two
levels, designed to best meet the processing needs at each of
the corresponding levels of abstraction in the interpretation
process. Communication between levels takes place via parallel
data and control paths. The processing elements within each
level can also communicate with each other in parallel, via a
different mechanism at each level that is designed to meet the
specific communication needs of each level of abstraction.
An associative processing paradigm has been utilized as the
principle control mechanism at the low and intermediate levels.
It provides a simple yet general means of managing massive
parallelism, through rapid responses to queries involving
partial matches of processor memory to broadcast values. This
has been enhanced with hardware operations that provide for
global broadcast, local compare, Some/None response, responder
count, and single responder select. To demonstrate how the
IUA may be used for vision processing, several simple algorithms
and a typical interpretation scenario on the IUA will be
presented.
We believe that the IUA represents a major step towards the
development of a proper combination of integrated processing
power, communication, and control required for real-time
computer vision. A proof-of-concept prototype of 1/64th of the
IUA is currently being constructed by the University of
Massachusetts and Hughes Research Laboratories.
BIOGRAPHY
Dr. Chip Weems received his B.S. and M.A. from Oregon State
University, where he first became interested in associative
architectures while working with the Nebula, an ONR sponsored
associative machine. His Ph.D. research was done at the
University of Massachusetts at Amherst under Dr. Caxton Foster,
who was an outspoken proponent of associative processing and who
worked on the STARAN and RADC 2048-word associative processors.
Since completing his Ph.D. in 1984, Dr. Weems has worked at
UMass in the area of parallel architectures in support of real-
time, knowledge-based computer vision. Since 1986, he has been
chief architect and director of the DARPA-sponsored Image Under-
standing Architecture project. He is also the co-author of two
best-selling introductory computer science textbooks.
-------
∂05-Aug-88 1141 ingrid@russell.stanford.edu Visiting Scholar cards
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Aug 88 11:41:12 PDT
Received: from russell.stanford.edu by csli.Stanford.EDU (4.0/4.7); Fri, 5 Aug 88 11:34:14 PDT
Received: from localhost by russell.stanford.edu (3.2/4.7); Fri, 5 Aug 88 11:38:16 PDT
To: research@russell.stanford.edu
Cc: ingrid@russell.stanford.edu
Subject: Visiting Scholar cards
Date: Fri, 05 Aug 88 11:38:15 PDT
From: ingrid@russell.stanford.edu
Will all of you who have Stanford Visiting Scholar cards please let me
know when they are going to expire so I can get you new ones?
You will need them to get your parking permits for the coming academic
year.
Thanks
Ingrid
∂06-Aug-88 1254 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu FIRST ANNUAL MEETING OF THE INTERNATIONAL NEURAL NETWORK SOCIETY
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Aug 88 12:54:15 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA05359; Sat, 6 Aug 88 12:53:34 PDT
Message-Id: <8808061953.AA05359@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Sat, 6 Aug 88 12:53:37 PDT
Received: by Forsythe.Stanford.EDU; Sat, 6 Aug 88 12:54:42 PDT
Received: by BYUADMIN (Mailer X1.25) id 8561; Sat, 06 Aug 88 13:12:30 MDT
Date: Mon, 1 Aug 88 11:53:22 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Michael Cohen <mike%bucasb.bu.edu%BU-IT.BU.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Michael Cohen <mike%bucasb.bu.edu%BU-IT.BU.EDU@Forsythe.Stanford.EDU>
Subject: FIRST ANNUAL MEETING OF THE INTERNATIONAL NEURAL NETWORK SOCIETY
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-----Meeting Update-----
September 6--10, 1988
Park Plaza Hotel
Boston, Massachusetts
The first annual INNS meeting promises to be a historic event. Its program
includes the largest selection of investigators ever assembled to present
the full range of neural network research and applications.
The meeting will bring together over 2000 scientists, engineers, students,
government administrators, industrial commercializers, and financiers. It
is rapidly selling out. Reserve now to avoid disappointment.
Call J.R. Shuman Associates, (617) 237-7931 for information about registration
For information about hotel reservations, call the Park Plaza Hotel at
(800) 225-2008 and reference "Neural Networks." If you call
from Massachusetts, call (800) 462-2022.
There will be 600 scientific presentations, including tutorials, plenary
lectures, symposia, and contributed oral and poster presentations. Over 50
exhibits are already reserved for industrial firms, publishing houses, and
government agencies.
The full day of tutorials presented on September 6 will be given by Gail
Carpenter, John Daugman, Stephen Grossberg, Morris Hirsch, Teuvo Kohonen,
David Rumelhart, Demetri Psaltis, and Allen Selverston. The plenary lecturers
are Stephen Grossberg, Carver Mead, Terrence Sejnowski, Nobuo Suga, and Bernard
Widrow. Approximately 30 symposium lectures will be given, 125 contributed oral
presentations, and 400 poster presentations.
Fourteen professional societies are cooperating with the INNS meeting. They
are:
American Association of Artificial Intelligence
American Mathematical Society
Association for Behavior Analysis
Cognitive Science Society
IEEE Boston Section
IEEE Computer Society
IEEE Control Systems Society
IEEE Engineering in Medicine and Biology Society
IEEE Systems, Man and Cybernetics Society
Optical Society of America
Society for Industrial and Applied Mathematics
Society for Mathematical Biology
Society of Photo-Optical Instrumentation Engineers
Society for the Experimental Analysis of Behavior
DO NOT MISS THE FIRST BIRTHDAY CELEBRATION OF THIS IMPORTANT NEW
RESEARCH COALITION!
∂06-Aug-88 1436 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu spokespeople
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Aug 88 14:36:44 PDT
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sat 6 Aug 88 14:33:57-PDT
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA01954; Sat, 6 Aug 88 14:33:45 PDT
Date: Sat, 6 Aug 88 14:33:45 PDT
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8808062133.AA01954@Tenaya.stanford.edu>
To: faculty@score
Subject: spokespeople
Last Spring I asked for comments and volunteers about my proposal to
appoint "spokespeople" for the four major interest areas of the
Department. (Happily, I got some positive comments and some capable
volunteers.) These people will help me maintain better contact with
the faculty and will play a role in coordinating some of the
interest-area-specific educational matters such as curriculum, quals,
etc. They will also help us set priorities about faculty growth and
provide suggestions about departmental policies in various areas. The
spokespeople and I will try to have regular bi-weekly meetings
starting this Fall.
Here is the lineup:
Theoretical Foundations of CS: John Mitchell
AI and Robotics: Jean-Claude Latombe
Scientific Computing: Joe Oliger
Systems: John Hennessy
They and I will be needing your cooperation to make this plan work.
Thanks,
-Nils
∂06-Aug-88 1445 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu 1988/89 CSD Committees
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Aug 88 14:45:48 PDT
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sat 6 Aug 88 14:42:53-PDT
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA01963; Sat, 6 Aug 88 14:42:40 PDT
Date: Sat, 6 Aug 88 14:42:40 PDT
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8808062142.AA01963@Tenaya.stanford.edu>
To: faculty@score
Cc: bmoore@ai.sri.com, hemenway@score, reges@polya
Subject: 1988/89 CSD Committees
CSD COMMITTEES FOR 1988/1989
Many of you have already been contacted about serving on the following
CSD committees. I hope the following committee membership suggestions
meet with everyone's approval. Please let me know if you have
concerns or problems with any of this. The committee structure is
changed a bit for the coming year. The major changes are:
1) The PhD committee will have two subsections with some overlap in
membership. One subsection will mainly be concerned with recruiting,
welcoming new students, and recommending policy for the PhD program.
The other subsection will deal solely with the PhD admission process
for 1989/1990. Mike Genesereth has agreed to be the overall chair and
will also be the chair of each subsection.
2) The "comprehensive committee will have three subsections---one for
each part of the exam (theory, applications, and systems). The
different subsection chairs should arrange to meet as an entire group
at least once to set overall exam policy, but then each can deal with
its part of the exam separately. I have recommended "chairs" for each
subsection and will work with these chairs to help them staff the
committees.
3) The curriculum committee will also be asked to make recommendations
about CSD teaching load. (Recall that it was decided at a recent
faculty meeting to look at the teaching load situation again and to
make recommendations about it.)
The chairs of all committees should confirm that their members have
received this note and are ready to serve. It would be appreciated by
many if committee meetings could be advertised so that interested
members of the Department could attend.
I presume that the student bureaucrats will be arranging for the
appointment of student members to these committees and will inform the
committee chairs.
To all others to whom this message comes, GREETINGS! If you would be
willing to serve on any of these committees please contact the chair,
cc-ing me.
-------
PhD Committee: Chair, Genesereth
Program, Policy, and Recruitment subsection. Supervises
Grey Tuesday/Black Friday proceedings. Arranges for "research
mentors" for first-year PhD students. Arranges CS 300
Autumn Quarter research seminar (where Department faculty and
others describe their research programs). Supervises PhD
recruitment and welcoming. Recommends PhD program policy.
Members: Genesereth (chair), Binford, Goldberg, Shoham, Hemenway
Admissions subsection. Decide which students admitted to CSD
PhD program.
Members: Genesereth (chair), Cheriton, Golub, Guibas, Lam,
McCarthy, Shoham, Hemenway, Ginsberg, Khatib, Shankar,
Moore (SRI)
Comprehensive Exam: Designs, administers and grades the two Comp Exams.
Theory subsection: Floyd (chair)
Applications subsection: Wiederhold (chair)
Systems subsection: Cheriton (chair)
Other members to be recruited after discussions with chairs.
Curriculum: Decides about CSD courses. Recommends teaching load policies.
Members: Guibas (chair), Floyd, Gupta, Jones, Reges
Facilities: Recommends plans and policies for CSD computer facilities.
Members: Rindfleisch (chair), Cheriton, Goldberg, Weise, Ball, Boyle,
Dienstbier, Wheaton
MS Program: Decides which students admitted to MS program. Recommends
plans and policies for MS program. Advises MS students.
Members: Oliger (chair), Binford, Dill, Latombe, Wiederhold, Winograd,
Hemenway, Jones, Keller, Reges
MSAI Program: Decides which students admitted to MSAI program. Recommends
plans and policies for MSAI program. Advises MSAI students.
(Currently in a "reduced-activity" state.)
Members: Engelmore (chair), Hayes-Roth, Hemenway.
CSD Undergraduate Major: Recommends plans and policies for the major.
Arranges for advising students.
Members: Winograd (chair), Gupta, Mitchell, Jones, Reges
Math/Comp. Sci. Major: Recommends plans and policies for the major.
Advises students.
Members: Golub (chair), Floyd, Herriot, Jones, Reges
Computer Systems Engrg. Major: Recommends plans and policies for the major.
Advises students.
Members: Hennessy (chair), Jones, Reges
Symbolic Systems Major: Recommends plans and policies for the major.
Advises students.
Members: Shoham (chair), Nilsson, Jones, Reges
Visiting Professors: Recommends Visiting Industrial Lectureships and
recommends and approves Departmental Visiting Professors.
Members: Goldberg (chair), Gupta, Sloan, Wheaton
Library and Publications: Recommends plans and policies for CSD library
and publication matters.
Members: Knuth (chair), Scott, Tajnai
Fellowships: Recommends student fellowship disposition.
Members: Tajnai (chair), Nilsson, Hemenway, Scott
Computer Forum: Recommends plans and policies for the CSD/CSL industrial
affiliates program.
Members: Miller (chair), Feigenbaum, Tajnai, DiMicheli, Wheaton
First Year PhD Student Advisor: Nilsson
Colloquium: Organizes CSD colloquium (to begin in Winter Quarter and
continue through Spring Quarter).
Members: Eppinger
Finance: Oversees CSD Financial Budgets and Expenditures.
Members: Wheaton (chair), Feigenbaum, Manna, Reges, Scott
∂09-Aug-88 1537 TAJNAI@Score.Stanford.EDU A New Milestone for the Computer Forum
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Aug 88 15:30:43 PDT
Date: Tue 9 Aug 88 15:15:02-PDT
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: A New Milestone for the Computer Forum
To: csd.list@Score.Stanford.EDU, csl-everyone@Sierra.Stanford.EDU
Message-ID: <12421150042.19.TAJNAI@Score.Stanford.EDU>
We just passed the one and a quarter million dollar milestone.
The Forum has brought in $1,260,432 plus $7,824 in our new Video Journal
Licensing Program.
The fiscal year ends 8/31, and we are already over $150,000 ahead
of 1986/87.
Three cheers for all of us!!
Carolyn Tajnai, the Forum staff and the Forum Committee
-------
∂10-Aug-88 0923 STAGER@Score.Stanford.EDU Grade sheets
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Aug 88 09:23:45 PDT
Date: Wed 10 Aug 88 09:20:18-PDT
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: Grade sheets
To: faculty@Score.Stanford.EDU, olkin@UNIX.SRI.COM, harden@Polya.Stanford.EDU,
katzman@Polya.Stanford.EDU, dimitri@Polya.Stanford.EDU,
nelson@Polya.Stanford.EDU, blee@Polya.Stanford.EDU, cer@Score.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12421347610.9.STAGER@Score.Stanford.EDU>
Summer Qtr grade sheets for both 8 and 10 week courses have arrived. Our
courier will be delivering them to mailboxes later today. Please complete
and return them to me at CS-TAC as soon as possible, and no later than
TUESDAY, AUGUST 30 at the latest.
Thanks.
Claire
-------
∂10-Aug-88 0936 @Score.Stanford.EDU:littell@polya.Stanford.EDU RAships
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Aug 88 09:36:35 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 10 Aug 88 09:34:03-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA26249; Wed, 10 Aug 88 09:35:07 PDT
Date: Wed, 10 Aug 88 09:35:07 PDT
From: Angelina M. Littell <littell@polya.Stanford.EDU>
Message-Id: <8808101635.AA26249@polya.Stanford.EDU>
To: faculty@score
Subject: RAships
Cc: littell@polya.Stanford.EDU
Please send me a list of students you plan to support during the
academic year 88/89, along with their source of support and percentage of
time. I need this information as soon as possible, if at all possible.
The RA appointment forms need to be processed soon so that the
students receive their bills with the correct tuition applied.
Thank you.
--Angie
∂11-Aug-88 1022 TOM@Score.Stanford.EDU
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Aug 88 10:22:49 PDT
Date: Thu 11 Aug 88 10:19:48-PDT
From: Thomas Dienstbier <TOM@Score.Stanford.EDU>
To: faculty@Score.Stanford.EDU, csd@Score.Stanford.EDU
Message-ID: <12421620585.24.TOM@Score.Stanford.EDU>
New digital combination locks have been installed on the machine
room(020) doors. The operation of these locks are as follows:
Door locks are un-locked, coded entry not required, between the
hours 0700-1800.
Door locks locked, coded entry required, between the hours 1800-0700.
Entry codes are available from Julie Baldwin for those who need access
to the machine room after hours.
These locks are to become operation starting friday morning, Aug 12.
Tom Dienstbier
CSDCF
-------
∂11-Aug-88 1029 SHOHAM@Score.Stanford.EDU orals
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Aug 88 10:29:23 PDT
Date: Thu 11 Aug 88 10:27:38-PDT
From: Yoav Shoham <SHOHAM@Score.Stanford.EDU>
Subject: orals
To: ac@Score.Stanford.EDU
Message-ID: <12421622012.36.SHOHAM@Score.Stanford.EDU>
Too late I learned about orals that took place yesterday and that I would
have liked to attend. Do we have an instituionalized way of notifying
faculty of upcoming orals? If not, I propose that we have one. Beside
making sure we can come to those orals we want to, it will probably
provide the best overview of the research going on here. I imagine the
students would welcome increased awareness of their work, too.
Yoav
-------
∂11-Aug-88 1444 X3J13-mailer CLOS workshop
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Aug 88 14:44:23 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 11 AUG 88 14:38:15 PDT
Date: Thu, 11 Aug 88 14:33 PDT
From: Gregor.pa@Xerox.COM
Subject: CLOS workshop
To: Common-Lisp@Sail.Stanford.edu, CommonLoops.pa@Xerox.COM,
X3J13@Sail.Stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest
Message-ID: <19880811213330.2.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
This is the second announcement of the CLOS workshop to be held at PARC
October 3rd and 4th. This is a reminder to help us with our planning by
letting us know soon if you are planning to attend. My apologies to
people who receive multiple copies of this message.
To clarify the position paper requirement, the workshop is not limited
exclusively to those who have extensive experience writing CLOS code.
Anyone planning CLOS implementations, extensions, environments or CLOS
based application development is encouraged to attend. A position paper
can simply be a description of the kinds of issues you feel should the
CLOS community should address at the workshop.
Workshop for CLOS Users and Implementors
October 3rd and 4th
Xerox PARC
Palo Alto, California
We have been excited by the extent to which CLOS is already being
used, and the ways in which it is being extended. The purpose of
this workshop is to provide an opportunity for the members of the
CLOS community to get together and share their experience.
To provide a good start for the interchange, we are requesting that
participants supply a short position paper (1-3 pages) describing
work related to CLOS. Some topics of interest are:
Applications
Programming Techniques
Implementation
Programming Environment Tools
Extensions of CLOS
Techniques for Converting to CLOS
Meta Object Techniques and Theory
Critiques
We will try to support demonstrations or videotapes of applications,
programming environments, implementations or other relevant systems.
If you are planning to attend, please let us know by August 15th.
This will help us with planning and allow us to arrange a discount
rate at a local hotel.
Position papers should reach us by September 9th so that we can
organize a program and arrange for duplication of the papers.
Position papers, notice to attend, and other correspondence should
be sent to:
Gregor Kiczales
3333 Coyote Hill Rd.
Palo Alto, CA 94304
or by Internet mail to:
Gregor.pa@Xerox.com
-------
∂11-Aug-88 1518 STAGER@Score.Stanford.EDU CS300
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Aug 88 15:18:18 PDT
Date: Thu 11 Aug 88 14:46:51-PDT
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: CS300
To: faculty@Score.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12421669201.27.STAGER@Score.Stanford.EDU>
We need someone to take charge of CS300 (Departmental Lecture Series) next
quarter. It's currently scheduled for Thursdays 4:15-5:30 in 320-334,
but we don't yet have anyone to run it. If one of you is willing to
make a (fairly minimal) time commitment to the course, please let me know.
A description follows:
Weekly presentations by members of the department faculty, each describing
informally his or her current research interests and views of computer
science as a whole. Recommended for first-year Computer Science graduate
students.
Thanks for your help.
Claire
-------
∂11-Aug-88 1607 X3J13-mailer CLOS workshop
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Aug 88 14:44:23 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 11 AUG 88 14:38:15 PDT
Date: Thu, 11 Aug 88 14:33 PDT
From: Gregor.pa@Xerox.COM
Subject: CLOS workshop
To: Common-Lisp@Sail.Stanford.edu, CommonLoops.pa@Xerox.COM,
X3J13@Sail.Stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest
Message-ID: <19880811213330.2.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
This is the second announcement of the CLOS workshop to be held at PARC
October 3rd and 4th. This is a reminder to help us with our planning by
letting us know soon if you are planning to attend. My apologies to
people who receive multiple copies of this message.
To clarify the position paper requirement, the workshop is not limited
exclusively to those who have extensive experience writing CLOS code.
Anyone planning CLOS implementations, extensions, environments or CLOS
based application development is encouraged to attend. A position paper
can simply be a description of the kinds of issues you feel should the
CLOS community should address at the workshop.
Workshop for CLOS Users and Implementors
October 3rd and 4th
Xerox PARC
Palo Alto, California
We have been excited by the extent to which CLOS is already being
used, and the ways in which it is being extended. The purpose of
this workshop is to provide an opportunity for the members of the
CLOS community to get together and share their experience.
To provide a good start for the interchange, we are requesting that
participants supply a short position paper (1-3 pages) describing
work related to CLOS. Some topics of interest are:
Applications
Programming Techniques
Implementation
Programming Environment Tools
Extensions of CLOS
Techniques for Converting to CLOS
Meta Object Techniques and Theory
Critiques
We will try to support demonstrations or videotapes of applications,
programming environments, implementations or other relevant systems.
If you are planning to attend, please let us know by August 15th.
This will help us with planning and allow us to arrange a discount
rate at a local hotel.
Position papers should reach us by September 9th so that we can
organize a program and arrange for duplication of the papers.
Position papers, notice to attend, and other correspondence should
be sent to:
Gregor Kiczales
3333 Coyote Hill Rd.
Palo Alto, CA 94304
or by Internet mail to:
Gregor.pa@Xerox.com
-------
∂11-Aug-88 1644 GILBERTSON@Score.Stanford.EDU [Thea Davis <DAVIS@Score.Stanford.EDU>: Parking Permits]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Aug 88 16:44:02 PDT
Date: Thu 11 Aug 88 16:32:03-PDT
From: Edith Gilbertson <GILBERTSON@Score.Stanford.EDU>
Subject: [Thea Davis <DAVIS@Score.Stanford.EDU>: Parking Permits]
To: CSD-List@Score.Stanford.EDU
Message-ID: <12421688353.20.GILBERTSON@Score.Stanford.EDU>
←
---------------
Mail-From: DAVIS created at 11-Aug-88 16:28:45
Date: Thu 11 Aug 88 16:28:44-PDT
From: Thea Davis <DAVIS@Score.Stanford.EDU>
Subject: Parking Permits
To: CSD@Score.Stanford.EDU
cc: Davis@Score.Stanford.EDU,
: ;
Message-ID: <12421687749.31.DAVIS@Score.Stanford.EDU>
Dear CSD Employees:
Thea Davis, the MJH receptionist, will be handling the parking
permit applications for CSD employees until August 31.
The Stanford Police Department is mailing parking permit applications
to all employees this week. You may turn in your completed application
to Thea -- on the second floor of Bldg 460. She will submit bulk mailings
of the applications to the Police Dept, and will receive your permits in
about two weeks. You may then pick up your parking permit/s at the
receptionist desk.
Please make sure to fill out BOTH sides of the application -- including
proper payment and your signature -- and submit it to Thea by August 31.
The employee bulk mailing convenience will be offered only until August 31.
After that date, you can mail your application directly to the Parking
Office in the Stanford Police Dept, including a self-addressed, double-
stamped envelope.
Happy 88/89 parking,
-Edie
-------
-------
∂11-Aug-88 1655 GILBERTSON@Score.Stanford.EDU [Edith Gilbertson <GILBERTSON@Score.Stanford.EDU>: MJH Carpet Cleaning Reminder]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Aug 88 16:55:05 PDT
Date: Thu 11 Aug 88 16:32:26-PDT
From: Edith Gilbertson <GILBERTSON@Score.Stanford.EDU>
Subject: [Edith Gilbertson <GILBERTSON@Score.Stanford.EDU>: MJH Carpet Cleaning Reminder]
To: CSD-List@Score.Stanford.EDU
Message-ID: <12421688422.20.GILBERTSON@Score.Stanford.EDU>
←
---------------
Mail-From: GILBERTSON created at 9-Aug-88 09:18:57
Date: Tue 9 Aug 88 09:18:57-PDT
From: Edith Gilbertson <GILBERTSON@Score.Stanford.EDU>
Subject: MJH Carpet Cleaning Reminder
To: CSD@Score.Stanford.EDU
cc: Gilbertson@Score.Stanford.EDU
Message-ID: <12421085219.36.GILBERTSON@Score.Stanford.EDU>
REMINDER:
The carpets in Margaret Jacks Hall - Bldg 460 - will be cleaned on
August 16 and 17 at 4 pm.
McNevin Cleaning Specialists will begin on the 4th and 3rd floors
on Tuesday, August 16 at 4pm. They will shampoo the 2nd floor carpet
and the 040 rooms in the basement on Wednesday, August 17 at 4pm
and into the evening.
McNevin's plans to do individual offices - around the bookcases and
heavy pieces of furniture and under the desks. Please pick up boxes
and miscellaneous items and place them out of the way so they can
reach more area in your office.
If you do not want your office cleaned, let me know and place
a large sign on your door on August 16.
Thank you for your cooperation,
-Edie
-------
←
-------
-------
∂13-Aug-88 1742 hoffman@csli.Stanford.EDU SSP Forum
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Aug 88 17:42:25 PDT
Received: from russell.stanford.edu by csli.Stanford.EDU (4.0/4.7); Sat, 13 Aug 88 17:41:56 PDT
Received: from csli.Stanford.EDU by russell.stanford.edu (3.2/4.7); Sat, 13 Aug 88 17:45:58 PDT
Received: by csli.Stanford.EDU (4.0/4.7); Sat, 13 Aug 88 17:41:54 PDT
Date: Sat 13 Aug 88 17:41:53-PDT
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: SSP Forum
To: ssp-faculty@RUSSELL.STANFORD.EDU
Message-Id: <587522513.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
It's just about time to begin seriously planning as much of next year's
Forum events as possible (especially fall). If you have any ideas or
suggestions please send them to me. If you wish to volunteer for some
presentation, also let me know. I have included some tentative (vague)
ideas for fall quarter in this message. (Incidentally, for those of you
wondering where I disappeared to this summer, I have just begun to recover
from mono.)
Tentative Ideas:
(1) Pat Hayes: Constructing Formalizations of Time
(2) Ivan Sag: Linguistics and Symbolic Systems
(3) CSLI (?): what is it all about?
(4) Various Groups of Interns presenting what they did
(5) Terry Winograd: either a presentation or a debate about AI and
hermeneutics
(6) SRI: presentation of the work which goes on in various groups over there
(7) A discussion on whether agents utilize representations or theorists merely
describe the agent's behaviour in terms of the use of representation?
(8) A discussion on the interface of the symbolic and the non-symbolic
(or, how do connectionism and classical AI stand in relation to each
other?)
(9) Dreyfus: either a presentation of his ideas of a debate
(10) Searle: likewise
(11) Etchemendy and Barwise: Logic and Symbolic Systems
(or "Why We Have To Take 160a")
there are others as well, but this gives you the idea.
I will also try, upon my own idea and upon suggestion, to attract speakers
from outside of Stanford. This requires a lot of effort and funds, however,
so cannot necessarily be counted on.
-------
∂14-Aug-88 0910 @Score.Stanford.EDU:WIEDERHOLD@SUMEX-AIM.Stanford.EDU Marriage Announcement
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Aug 88 09:10:08 PDT
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 14 Aug 88 09:07:03-PDT
Date: Sun, 14 Aug 88 09:05:00 PDT
From: Gio Wiederhold <WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
Subject: Marriage Announcement
To: faculty@score.Stanford.EDU
Message-ID: <12422393400.19.WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
On Saturday, Aug.14, Diane Forsythe, daughter of Sandra and George Forsythe,
the founder of our CS department, married Gerard Schutte. They will live
in Evanston, Il.
-------
∂14-Aug-88 1820 hayes.pa@Xerox.COM Re: rough draft SSP reading list
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Aug 88 18:20:18 PDT
Received: from russell.stanford.edu by csli.Stanford.EDU (4.0/4.7); Sun, 14 Aug 88 18:19:40 PDT
Received: from Xerox.COM by russell.stanford.edu (3.2/4.7); Sun, 14 Aug 88 18:23:38 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 14 AUG 88 18:18:39 PDT
Date: 14 Aug 88 17:44 PDT
From: hayes.pa@Xerox.COM
Subject: Re: rough draft SSP reading list
In-Reply-To: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>'s message of Sat, 13 Aug
88 17:11:52 PDT
To: HOFFMAN@CSLI.Stanford.EDU
Cc: ssp-faculty@RUSSELL.STANFORD.EDU
Message-Id: <880814-181839-1026@Xerox>
Its rather a long list to just be confronted with without any guidance. Also,
the rigor level is very mixed ( eg all the way from Hofstadter,
Winograd/Flores, Dreyfus....up to Barwise/Etchemendy, Rumelhart/McClelland and
Sussman ) and also there is a mix between books about the meta-ssp ( whether AI
is sound, etc: such stuff as Dreyfus[all of it] and Winograd/Flores and
Haugeland ) and those which work within some assumed intellectual tradition (
such as Sag et al, Winograd on Syntax, Nilsson/Genesereth, Dretske and Searle ).
And some are explicitly catholic overviews or collections of essays, others
grind a particular axe very narrowly. Also, why include such oldsters as Whorf
( not Wharf ) and Wittgenstein? If we cast our net this widely then we ought to
include all sorts of stuff, eg Ryle `On MInd' , just to give a balanced picture.
Vehicles is by Valentino Braitenberg, MIT press. Why include this ( apart from
entertainment value ) or the Hodges biography?
But a good start, well done!
Pat
∂14-Aug-88 1820 hayes.pa@Xerox.COM Re: SSP Forum
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Aug 88 18:20:23 PDT
Received: from russell.stanford.edu by csli.Stanford.EDU (4.0/4.7); Sun, 14 Aug 88 18:19:53 PDT
Received: from csli by russell.stanford.edu (3.2/4.7); Sun, 14 Aug 88 18:23:50 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 14 AUG 88 18:18:43 PDT
Date: 14 Aug 88 17:50 PDT
From: hayes.pa@Xerox.COM
Subject: Re: SSP Forum
In-Reply-To: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>'s message of Sat, 13 Aug
88 17:41:53 PDT
To: HOFFMAN@CSLI.Stanford.EDU
Cc: ssp-faculty@RUSSELL.STANFORD.EDU
Message-Id: <880814-181843-1027@Xerox>
> Tentative Ideas:
> (1) Pat Hayes: Constructing Formalizations of Time
I will be giving a CS course on this ( more or less ) in the fall.
>(5) Terry Winograd: either a presentation or a debate about AI and
> hermeneutics
Id like to hear what is meant by `hermeneutics', said in a way which makes clear
what possible connection it can have with ANY scientific enterprise.
Pat
∂15-Aug-88 0904 @polya.Stanford.EDU:ARK@SAIL.Stanford.EDU Adv. Pgm.: Int. Symp. on Parallel and Distrib Systems, Dec 5-7, 88
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Aug 88 09:04:51 PDT
Received: from Sail.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA13129; Mon, 15 Aug 88 08:58:52 PDT
Message-Id: <kSWiF@SAIL.Stanford.EDU>
Date: 15 Aug 88 0859 PDT
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Adv. Pgm.: Int. Symp. on Parallel and Distrib Systems, Dec 5-7, 88
To: CS545-PEOPLE@SRI.COM, NAIL@Polya.Stanford.EDU
Cc: sjajodia@NOTE.NSF.GOV
ADVANCE PROGRAM
INTERNATIONAL SYMPOSIUM ON DATABASES IN
PARALLEL AND DISTRIBUTED SYSTEMS
December 5-7, 1988
Austin, Texas
Sponsored by: IEEE CS Technical Committee on Data Engineering
ACM SIG on Computer Architecture
=====================================================================
December 5, 1st Day
2 Tutorials 8:30 - 12:00
Opening Remarks
1:00 - 1:15 Joe Urban - University of Miami, Florida
1:15 - 1:30 Won Kim, MCC
Keynote Address
1:30 - 2:15 J.C. Browne - University of Texas at Austin
Session 1 2:30 - 3:45 Object-Oriented Systems
Chair: Gerald Karam - Carleton University
"The Relation between Problems in Large-Scale Concurrent Systems and
Distributed Databases (invited paper)"
Gul Agha - Yale University
"Writing Reliable Servers: Design and Implementation
in Avalon/C++
Richard Allen Lerner - Carnegie Mellon University
"Performance Modeling of Distributed Object-Oriented
Database Systems"
Jeffrey A. Brumfield - University of Texas at Austin
Janet Miller, Hong-Tai Chou - MCC
Break
Session 2 4:00 - 5:30 Logic-Based Systems
Chair: Ravi Krishnamurthy - MCC
"Exploiting Concurrency in a DBMS Implementation
for Production Systems"
Louiqa Raschid, Timos Sellis,
Chih-Chen Lin - University of Maryland
"Sharing the Load of Logic-Program Evaluation"
Ouri Wolfson - The Techniion-Israel Institute
of Technology
"Multiprocessor Transitive Closure Algorithms"
Rakesh Agrawal, H. V. Jagadish - AT&T Bell Laboratories
Reception 6:00 - 9:00
December 6, 2nd Day
Session 3 9:00 - 10:30 Parallel Database Systems
Chair: Rakesh Agrawal - AT&T Bell Laboratories
"Parallelism in Bubba (invited paper),"
Haran Boral - MCC
"Parallelizing FAD, a Database Programming Language:
Brian Hart, Scott Danforth, Patrick Valduriez - MCC
"JAS: A Parallel VLSI Architecture for Unformatted
Data Processing"
K.C. Lee, O. Frieder, V. Mak - Bell Communications
Research
Break
Session 4 11:00 - 12:30 Parallel Join
Chair: Anil Nigam - IBM Thomas J. Watson Lab.
"Parallel Join Algorithms on a Network of Workstations"
Xiao Wang, W.S. Luk - Simon Fraser University
"A Robust Protocol for Parallel Join Operations
in Distributed Data Bases"
S. Bandyopadhyay, A. Sengupta - University of Windsor
"Effect of Skew on Join Performance in Parallel
Architectures"
M. Seetha Lakshmi, Philip S. Yu - IBM Thomas J. Watson Lab.
Session 5 2:00 - 3:30
Panel: chair: John Carlis - University of Minnesota
"Parallelism in Databases: What, Why, and Whither"
Break
Session 6 4:00 - 5:30 Distributed Query Processing
Chair: Hong-Tai Chou - MCC
"A Case Study for Distributed Query Processing"
P. Agrawal, D. Bitton, K. Guh, C. Liu,
C. Yu - University of Illinois at Chicago
"Parallelism in Processing Queries on Complex
Objects"
T. Harder, H. Schoning, A. Sikeler - University
Kaiserslautern
"Heuristic Algorithms for Distributed Query
Processing"
P. Bodorik - Technical University of Nova Scotia
J.S. Riordon - Carleton University
Reception 6:00 - 9:00
December 7, 3rd Day
Session 7 9:00 - 10:30 Transaction Processing
Chair: Sunil Sarin - Computer Corp. of America
"Note Autonomy in Distributed Systems (invited paper),"
Hector Garcia-Molina, Boris Kogan - Princeton University
"Performance Evaluation of Global Reading of
Entire Databases"
Calton Pu, Christine H. Hong, Jae M. Wha -
Columbia University
"Multiprocessor Main Memory Transaction Processing"
Kai Li, Jeffrey F. Naughton - Princeton University
Break
Session 8 11:00 - 12:30 Distributed Databases
Chair: Ophir Frieder - Bell Comm. Res.
"VIP-MDBS: A Logic Multidatabase System"
Eva Kuhn, Thomas Ludwig - Technische Universitat
Wien, Austria
"Integrating Relational Databases with Support
for Updates"
M. Samy Gamal-Edin - Clarkson University
Gomer Thomas - Bell Communications Research
Ramez Elmasri - University of Houston
"Robust Transaction Routing in Distributed
Database Systems"
Yann-Hang Lee, Philip S. Yu - IBM Thomas J. Watson Lab.
===========================================================
Tutorial #1: Parallel Computing and Database Management
Instructor: Bruce K. Hilyer, AT&T Bell Labs
============================================================
Tutorial #2: Integrating Heterogeneous Distributed Databases:
Requirements, Concepts, and Solutions
Instructors: Ahmed K. Elmagarmid, Purdue U. and
Amith P. Sheth, UNISYS
===============================================================
For registration information, send a message to Sushil Jajodia
at sjajodia@note.nsf.gov.
∂15-Aug-88 1729 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu polymorphism versus macroexpansion
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Aug 88 17:29:02 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA04801; Mon, 15 Aug 88 15:51:39 PDT
Message-Id: <8808152251.AA04801@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Mon, 15 Aug 88 15:52:03 PDT
Received: by Forsythe.Stanford.EDU; Mon, 15 Aug 88 15:53:07 PDT
Received: by BYUADMIN (Mailer X1.25) id 8733; Mon, 15 Aug 88 16:47:34 MDT
Date: Mon, 15 Aug 88 14:14:31 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Mr Jack Campin <mcvax!ukc!strath-cs!glasgow!jack@UUNET.UU.NET>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Mr Jack Campin <mcvax!ukc!strath-cs!glasgow!jack@UUNET.UU.NET>
Subject: polymorphism versus macroexpansion
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Can anyone point me to some work that describes the limits of polymorphism
implemented by an Ada-like macro-expansion technique? I can think of some
recursive types that can't be checked that way, but would like a precise
description of its limitations.
--
ARPA: jack%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk USENET: jack@cs.glasgow.uucp
JANET:jack@uk.ac.glasgow.cs useBANGnet: ...mcvax!ukc!cs.glasgow.ac.uk!jack
Mail: Jack Campin, Computing Science Dept., Glasgow Univ., 17 Lilybank Gardens,
Glasgow G12 8QQ, SCOTLAND work 041 339 8855 x 6045; home 041 556 1878
∂15-Aug-88 1748 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Can someone suggest a good survey articles on Complexity?
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Aug 88 17:48:08 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA04696; Mon, 15 Aug 88 15:48:35 PDT
Message-Id: <8808152248.AA04696@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Mon, 15 Aug 88 15:48:59 PDT
Received: by Forsythe.Stanford.EDU; Mon, 15 Aug 88 15:49:47 PDT
Received: by BYUADMIN (Mailer X1.25) id 8619; Mon, 15 Aug 88 16:46:56 MDT
Date: Mon, 15 Aug 88 14:05:56 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Sun, Kang" <yalevm!SUNKANA@YALE-BULLDOG.ARPA>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Sun, Kang" <yalevm!SUNKANA@YALE-BULLDOG.ARPA>
Subject: Can someone suggest a good survey articles on Complexity?
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
I was asked to give an introduction talk to Complexity Theory, e.g. NP-
complete. Before that I need to hand out some reference. Can anyone sugge
an good survey article on this topic? Perhaps one that is not too difficu
Have anyone seen anything on Scientific American or Spectrum etc? Thanks.
∂15-Aug-88 1748 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu my left-over proceedings are sold already
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Aug 88 17:48:20 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA04750; Mon, 15 Aug 88 15:50:08 PDT
Message-Id: <8808152250.AA04750@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Mon, 15 Aug 88 15:50:32 PDT
Received: by Forsythe.Stanford.EDU; Mon, 15 Aug 88 15:51:17 PDT
Received: by BYUADMIN (Mailer X1.25) id 8678; Mon, 15 Aug 88 16:47:15 MDT
Date: Mon, 15 Aug 88 14:09:42 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Ian Parberry <ian%PSUVAXS.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Ian Parberry <ian%PSUVAXS.BITNET@forsythe.stanford.edu>
Subject: my left-over proceedings are sold already
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
> Due to some confusion, I find myself with two extra copies of the 1988
> STOC proceedings. I am willing (eager) to part with them at the cost price
> of $25, a substantial savings over the regular price. I will pay any
> (reasonable) postage costs.
I am happy to say that the proceedings have found new owners.
The flood of responses was unexpected, and indicates a healthy
level of interest in theoretical computer science.
--------------------------------------------------------------------------------
Ian Parberry ian@psuvax1.cs.psu.edu ian@psuvax1.BITNET ian@psuvax1.UUCP
Dept of Comp Sci, 333 Whitmore Lab, Penn State Univ, University Park, Pa. 16802
∂15-Aug-88 1808 LOGMTC-mailer Next LICS
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Aug 88 18:08:36 PDT
Received: from russell.stanford.edu by csli.Stanford.EDU (4.0/4.7); Mon, 15 Aug 88 17:04:03 PDT
Received: from localhost by russell.stanford.edu (3.2/4.7); Mon, 15 Aug 88 17:07:59 PDT
To: logic@russell.stanford.edu
Subject: Next LICS
Date: Mon, 15 Aug 88 17:07:55 PDT
From: Jon Barwise <barwise@russell.stanford.edu>
CALL FOR PAPERS
Logic in Computer Science (LICS)
Fourth Annual Symposium
June 5-8, 1989, Asilomar, California
The Symposium will cover a wide range of theoretical and practical issues
in Computer Science that relate to logic in a broad sense, including
algebraic and topological approaches.
Suggested (but not exclusive) topics of interest include: abstract data
types, computer theorem proving, concurrency, data base theory, knowledge
representation, finite model theory, lambda and combinatory calculi, logic
programming, logics in artificial intelligence, modal and temporal logics,
program logic and semantics, software specification, types and categories,
constructive mathematics, verification.
Paper submission: 15 copies of a detailed abstract (not a full paper)
should be RECEIVED by October 21, 1988 by the program chairman:
Prof. Rohit Parikh - LICS
Department of Computer Science
Brooklyn College of CUNY
Bedford Avenue & Avenue H
Brooklyn, NY 11210, U.S.A.
Bitnet: RIPBC@CUNYVM Internet: ripbc@cunyvm.cuny.edu
NB: papers from outside the U.S.A. should arrive by October 25.
Abstracts must be clearly written and provide sufficient detail to allow
the program committee to assess the merits of the paper. References and
comparisons with related work should be included where appropriate. The
entire extended abstract should not exceed 10 double-spaced pages in
10 or 12-point font (2500 words). Late abstracts, or those departing
significantly from these guidelines, run a high risk of not being considered.
The authors will be notified of acceptance or rejection by December 23,
1988. Accepted papers, typed on special forms for inclusion in the symposium
proceedings, will be due February 20, 1989.
The symposium is sponsored by the IEEE Technical Committee on
Mathematical Foundations of Computing, in cooperation with ACM
SIGACT, ASL, and EATCS.
Program Committee: Martin Davis, Melvin Fitting, Matthew Hennessey, David
Israel, Joxan Jaffar, Deborah Joseph, Deepak Kapur, Dennis Kfoury, Phokion
Kolaitis, Dexter Kozen, Vladimir Lifschitz, Rohit Parikh (chair), Amir Pnueli,
Vaughan Pratt, Rick Statman.
Organizing Committee: J. Barwise, W. Bledsoe, A. Chandra, E. Dijkstra,
E. Engeler, J.Goguen, D. Gries, Y. Gurevich, D. Kozen, Z. Manna,
A. Meyer (chair), R.Parikh, G.Plotkin, D.Scott.
Conference Chair Local Arrangements Chair
Prof. Albert R. Meyer Martin Abadi
Laboratory for Computer Science Digital Equipment Corporation
MIT Systems Research Center
545 Technology Square 130 Lytton Avenue
Cambridge, MA 02139, U.S.A. Palo Alto, CA 94301, U.S.A.
Internet: meyer@theory.lcs.mit.edu ma@src.dec.com
------- End of Forwarded Message
∂16-Aug-88 1047 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu TCS geneology
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Aug 88 10:47:15 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA00451; Tue, 16 Aug 88 10:46:01 PDT
Message-Id: <8808161746.AA00451@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Tue, 16 Aug 88 10:46:24 PDT
Received: by Forsythe.Stanford.EDU; Tue, 16 Aug 88 10:46:19 PDT
Received: by BYUADMIN (Mailer X1.25) id 3684; Tue, 16 Aug 88 11:09:03 MDT
Date: Mon, 15 Aug 88 14:18:49 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Ian Parberry <ian%PSUVAXS.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Ian Parberry <ian%PSUVAXS.BITNET@forsythe.stanford.edu>
Subject: TCS geneology
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
This is an official call for updates to the Theoretical Computer Science
geneological data-base (see David S. Johnson, "The Geneology of
Theoretical Computer Science", SIGACT News 16(2) (1984) 36-44,
and EATCS Bulletin 25 (1985) 198-211).
If you can provide corrections to the data-base, answer any
of the open problems listed there, or provide new entries,
please send them to one of the addresses below (email preferred),
rather than to David Johnson.
The following classes of individuals are eligible for inclusion
in the data-base. New entries are welcome to indicate into which
class they fall. The guidelines can be interpreted liberally, since,
to quote David Johnson: "The intent ... is to ensure that all
contributing members of the community are included, and to guarantee
that interesting connections to the outside world can be pointed out".
(A) Ph. D.'s who
(1) have written a significant paper in theoretical computer science
(in a refereed theoretical computer science journal or conference).
(2) regularly attend STOC/FOCS conferences.
(B) Advisor of a member of (A).
(C) Famous person from another field (computer science, mathematics, physics,
politics etc.) who has an ancestor who has a descendant in (A).
(D) All of the people whose inclusion links (C) to (A).
Naturally, we are most interested in classes (A) and (B).
-------------------------------------------------------------------------------
Ian Parberry
ian@psuvax1.cs.psu.edu ian@psuvax1.BITNET ian@psuvax1.UUCP (814) 863-3600
Dept of Comp Sci, 333 Whitmore Lab, Penn State Univ, University Park, Pa 16802
∂16-Aug-88 1047 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu LICS '89
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Aug 88 10:47:34 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA00458; Tue, 16 Aug 88 10:46:14 PDT
Message-Id: <8808161746.AA00458@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Tue, 16 Aug 88 10:46:38 PDT
Received: by Forsythe.Stanford.EDU; Tue, 16 Aug 88 10:46:30 PDT
Received: by BYUADMIN (Mailer X1.25) id 3932; Tue, 16 Aug 88 11:12:21 MDT
Date: Mon, 15 Aug 88 14:26:00 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Rohit Parikh <RIPBC%CUNYVM.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Rohit Parikh <RIPBC%CUNYVM.BITNET@forsythe.stanford.edu>
Subject: LICS '89
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
CALL FOR PAPERS
Logic in Computer Science (LICS)
Fourth Annual Symposium
June 5-8, 1989, Asilomar, California
The Symposium will cover a wide range of theoretical and practical issues
in Computer Science that relate to logic in a broad sense, including
algebraic and topological approaches.
Suggested (but not exclusive) topics of interest include: abstract data
types, computer theorem proving, concurrency, data base theory, knowledge
representation, finite model theory, lambda and combinatory calculi, logic
programming, logics in artificial intelligence, modal and temporal logics,
program logic and semantics, software specification, types and categories,
constructive mathematics, verification.
Paper submission: 15 copies of a detailed abstract (not a full paper)
should be RECEIVED by October 21, 1988 by the program chairman:
Prof. Rohit Parikh - LICS
Department of Computer Science
Brooklyn College of CUNY
Bedford Avenue & Avenue H
Brooklyn, NY 11210, U.S.A.
Bitnet: RIPBC@CUNYVM Internet: ripbc@cunyvm.cuny.edu
NB: papers from outside the U.S.A. should arrive by October 25.
Abstracts must be clearly written and provide sufficient detail to allow
the program committee to assess the merits of the paper. References and
comparisons with related work should be included where appropriate. The
entire extended abstract should not exceed 10 double-spaced pages in
10 or 12-point font (2500 words). Late abstracts, or those departing
significantly from these guidelines, run a high risk of not being considered.
The authors will be notified of acceptance or rejection by December 23,
1988. Accepted papers, typed on special forms for inclusion in the symposium
proceedings, will be due February 20, 1989.
The symposium is sponsored by the IEEE Technical Committee on
Mathematical Foundations of Computing, in cooperation with ACM
SIGACT, ASL, and EATCS.
Program Committee: Martin Davis, Melvin Fitting, Matthew Hennessey, David
Israel, Joxan Jaffar, Deborah Joseph, Deepak Kapur, Dennis Kfoury, Phokion
Kolaitis, Dexter Kozen, Vladimir Lifschitz, Rohit Parikh (chair), Amir Pnueli,
Vaughan Pratt, Rick Statman.
Organizing Committee: J. Barwise, W. Bledsoe, A. Chandra, E. Dijkstra,
E. Engeler, J.Goguen, D. Gries, Y. Gurevich, D. Kozen, Z. Manna,
A. Meyer (chair), R.Parikh, G.Plotkin, D.Scott.
Conference Chair Local Arrangements Chair
Prof. Albert R. Meyer Martin Abadi
Laboratory for Computer Science Digital Equipment Corporation
MIT Systems Research Center
545 Technology Square 130 Lytton Avenue
Cambridge, MA 02139, U.S.A. Palo Alto, CA 94301, U.S.A.
Internet: meyer@theory.lcs.mit.edu ma@src.dec.com
∂16-Aug-88 1048 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Neural Computation
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Aug 88 10:48:26 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA00506; Tue, 16 Aug 88 10:47:02 PDT
Message-Id: <8808161747.AA00506@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Tue, 16 Aug 88 10:47:25 PDT
Received: by Forsythe.Stanford.EDU; Tue, 16 Aug 88 10:46:53 PDT
Received: by BYUADMIN (Mailer X1.25) id 4361; Tue, 16 Aug 88 11:24:56 MDT
Date: Mon, 15 Aug 88 14:36:18 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Terry Sejnowski <terry%CS.JHU.EDU@Forsythe.Stanford.EDU>" <terry%CS.JHU.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Terry Sejnowski <terry%CS.JHU.EDU@Forsythe.Stanford.EDU>" <terry%CS.JHU.EDU@Forsythe.Stanford.EDU>
Subject: Neural Computation
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
Announcement and
Call for Papers
NEURAL COMPUTATION
First Issue: Spring 1989
Editor-in-Chief
Terrence Sejnowski
The Salk Institute and
The University of California at San Diego
Neural Computation will provide a unique interdisciplinary forum
for the dissemination of important research results and for
reviews of research areas in neural computation.
Neural computation is a rapidly growing field that is attracting
researchers in neuroscience, psychology, physics, mathematics,
electrical engineering, computer science, and artificial
intelligence. Researchers within these disciplines address,
from special perspectives, the twin scientific and engineering
challenges of understanding the brain and building computers.
The journal serves to bring together work from various
application areas, highlighting common problems and techniques
in modeling the brain and in the design and construction of
neurally-inspired information processing systems.
By publishing timely short communications and research reviews,
Neural Computation will allow researchers easy access to
information on important advances and will provide a valuable
overview of the broad range of work contributing to neural
computation. The journal will not accept long research
articles.
The fields covered include neuroscience, computer science,
artificial intelligence, mathematics, physics, psychology,
linguistics, adaptive systems, vision, speech, robotics, optical
computing, and VLSI.
Neural Computation is published quarterly by The MIT Press.
Board of Editors
Editor-in-Chief: Terrence Sejnowski, The Salk Institute and
The University of California at San Diego
Advisory Board:
Shun-ichi Amari, University of Tokyo, Japan
Michael Arbib, University of Southern California
Jean-Pierre Changeux, Institut Pasteur, France
Leon Cooper, Brown University
Jack Cowan, University of Chicago
Jerome Feldman, University of Rochester
Teuovo Kohonen, University of Helsinki, Finland
Carver Mead, California Institute of Technology
Tomaso Poggio, Massachusetts Institute of Technology
Wilfrid Rall, National Institutes of Health
Werner Reichardt, Max-Planck-Institut fur Biologische Kybernetik
David A. Robinson, Johns Hopkins University
David Rumelhart, Stanford University
Bernard Widrow, Stanford University
Action Editors:
Joshua Alspector, Bell Communications Research
Richard Andersen, MIT
James Anderson, Brown University
Dana Ballard, University of Rochester
Harry Barrow, University of Sussex
Andrew Barto, University of Massachusetts
Gail Carpenter, Northeastern University
Gary Dell, University of Rochester
Gerard Dreyfus, Paris, France
Jeffrey Elman, University of California at San Diego
Nabil Farhat, University of Pennsylvania
Francois Fogelman-Soulie, Paris, France
Peter Getting, University of Iowa
Ellen Hildreth, Massachusetts Institute of Technology
Geoffrey Hinton, University of Toronto, Canada
Bernardo Huberman, Xerox, Palo Alto
Lawrence Jackel, AT&T Bell Laboratories
Scott Kirkpatrick, IBM Yorktown Heights
Christof Koch, California Institute of Technology
Richard Lippmann, Lincoln Laboratories
Stephen Lisberger, University of California San Francisco
James McClelland, Carnegie-Mellon University
Graeme Mitchison, Cambridge University, England
David Mumford, Harvard University
Erkki Oja, Kuopio, Finland
Andras Pellionisz, New York University
Demetri Psaltis, California Institute of Technology
Idan Segev, The Hebrew University
Gordon Shepherd, Yale University
Vincent Torre, Universita di Genova, Italy
David Touretzky, Carnegie-Mellon University
Roger Traub, IBM Yorktown Heights
Les Valiant, Harvard University
Christoph von der Malsburg, University of Southern California
David Willshaw, Edinburgh, Scotland
John Wyatt, Massachusetts Institute of Technology
Steven Zucker, McGill University, Canada
Instructions to Authors
The journal will consider short communications, having no more
than 2000 words of text, 4 figures, and 10 citations; and area
reviews which summarize significant advances in a broad area of
research, with up to 5000 words of text, 8 figures, and 100
citations. The journal will accept one-page summaries for
proposed reviews to be considered for solicitation.
All papers should be submitted to the editor-in-chief. Authors
may recommend one or more of the action editors. Accepted
papers will appear with the name of the action aditor that
communicated the paper.
Before January 1, 1989, please address submissions to:
Dr. Terrence Sejnowski
Biophysics Department
Johns Hopkins University
Baltimore, MD 21218
After January 1, 1989, please address submissions to:
Dr. Terrence Sejnowski
The Salk Institute
P.O. Box 85800
San Diego, CA 92138
Subscription Information
Neural Computation
Annual subscription price (four issues):
$90.00 institution
$45.00 individual
(add $9.00 surface mail or $17.00 airmail postage
outside U.S. and Canada)
Available from:
MIT Press Journals
55 Hayward Street
Cambridge, MA 02142
USA
617-253-2889
∂16-Aug-88 1048 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Kolmogorov Complexity is not "decidable"
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Aug 88 10:48:32 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA00504; Tue, 16 Aug 88 10:46:55 PDT
Message-Id: <8808161746.AA00504@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Tue, 16 Aug 88 10:47:19 PDT
Received: by Forsythe.Stanford.EDU; Tue, 16 Aug 88 10:46:45 PDT
Received: by BYUADMIN (Mailer X1.25) id 4286; Tue, 16 Aug 88 11:23:06 MDT
Date: Mon, 15 Aug 88 14:33:15 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Robert M. Solovay" <agate!frito!solovay%UCBVAX.BERKELEY.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Robert M. Solovay" <agate!frito!solovay%UCBVAX.BERKELEY.EDU@Forsythe.Stanford.EDU>
Subject: Re: Kolmogorov Complexity is not "decidable"
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
In article <8806271507.AA04350@jade.berkeley.edu> TheoryNet List
<THEORYNT%NDSUVM1.bitnet@jade.berkeley.edu>, Vaughan Pratt
<coraki!pratt@sun.com> writes:
[Some introductory material omitted]
>Definition. Let KC = {<W,n>| Kolmog(W) <= n}, that is, the set of pairs
><W,n> for which the Kolmogorov complexity of W is at most n.
>
>Theorem 1 (equivalent form). KC is not a recursive set (i.e.
>membership in KC is undecidable).
>
>Theorem 2. KC is r.e. (i.e. membership in KC is partially decidable).
>
>Proof. To enumerate KC run all Turing machines in parallel,
>initializing each to state q0 with blank tape. Whenever some machine M
>halts, output <W,|M|> where W is whatever M left on its tape.
>
>Conjecture 3. KC is not complete (= r.e.-complete).
>
>Prior to Friedberg-Muchnik (see Rogers) all known non-recursive r.e.
>sets were complete. Even today the nonrecursiveness of an r.e. set is
>almost invariably proved by showing that it is complete, witness the
>"proof" that Jamie Andrews was rightly objecting to, which in effect
>was inferring Theorem 1 from a "howler" proof of the negation of
>Conjecture 3. Friedberg and Muchnik's independently discovered result
>that there exist nonrecursive noncomplete r.e. sets still appears to be
>reasonably deep. If Conjecture 3 holds then it implies
>Friedberg-Muchnik and hence is at least as deep a result; furthermore
>KC would then surely constitute the most natural example to date of
>such a set.
>
>
>I would be interested to hear from any experts in the area with
>information about previous work on or statement of this conjecture.
>
> Vaughan Pratt
> Stanford University
> Sun Microsystems
> Triangle Concepts
The set KC introduced by Pratt is indeeed a complete r.e. set.
In what follows, I sketch a proof of this. This is analogous to a
result in the Chaitin theory of the Kolmogorov complexity of strings;
because an apparantly different notion of "Kolmogorov complexity" is
used than that usually employed one can't immediately cite the Chaitin
result. (For all I know, it is possible to argue that the new notion
has the same formal properties as the Kolmogorov notion and directly
cite the Chaitin result. Also, the result in question is probably due
also to Kolmogorov or one of his students or disciples--Levin, Gac,
etc.)
Before beginning the proof proper, it is probably worth
recalling the variant of Kolmogorov complexity being used. We are
assigning a complexity to each string s on the two element alphabet
{0,1}. This Kolmogorov complexity is the least N such that there is a
machine with at most N states which started in the standard initial
conditions of empty tape and state q_0 will eventually halt with s on
its output tape. All machines consider are 1-tape machines with a
fixed working alphabet A (which may be larger than {0,1}. In thinking
through the details of the proof presented below, I have assumed that
A has at least two additional symbols, namely the blank symbol and a
"comma".
Let K be some standard complete r. e. set. We identify the
non-negative integers with the strings on the two element alphabet
{0,1} in some standard primitive recursive way. We shall assign to
each non-negative integer x a Turing machine M_x such that the
following holds:
1) x is a member of K iff M_x halts (started in the standard
initial conditions of state q_0 scanning an empty tape).
2) Suppose that x is a member of K and that t is the time at
which x is enumerated into K. Then the ouput of M_x is a string s such
that if N is the number of states of M_x then no Turing machine M'
with at most N states outputs s in at most t steps.
3) M_x can be computed from x by a primitive recursive
function.
4) The length of the string s is given by some explicit
primitive recursive function of M_x.
Granted this construction, we may give the following algorithm
that computes K from Pratt's KC:
Given x. First compute M_x and its number of states N. Also,
compute (as allowed by 4) the length of the string which will be ouput
by M_x if it hallts at all. Call this length r. Now, using KC, we can
determine the number of strings of length r whose Kolmogorov
complexity as defined in Pratt's posting is at most N. Call this
number s.
Now run simultaneously all Turing machines with at most N
states (starting in the standard initial conditions described above)
until the least time t* when at least s distinct strings have been
output of length r. The definition of s insures that this wait will
terminate in a time t* rather than go on forever. Now see if x has
been listed in K by time t*. If it hasn't, the properties of M_x
insure that x is not in K. Thus we have described an algorithm for
computing K from KC.
It remains to construct M_x from x. We assume given a
reasonable primitive recursive Godel numbering of our class of Turing
machines. We shall employ a version of the recursion theorem with
parameters for our class of Turing machines. This asserts that if
f(x,e) is a partial recursive function, then there is a primitive
recursive function which takes x into a Turing machine M_x such that
M_x will halt (under the standard initial conditions) iff f(x,e) is
defined where e is the Godel number of M_x. Moreover, if it does halt,
the contents of its tape upon halting will be f(x,e).
It remains to describe the function f(x,e). The function first
waits till the time t when x enters the complete r.e. set K. If x is
not in K, then the program will wait forever and f(x,e) will be
undefined.
It next computes from e the number of states, N, that M_x will
have, and then the number of Turing machines with at most N states. It
can then easily find a number r such that some string of length r will
not have Kolmogorov complexity at most N. (The program simply chooses
the least r such that 2*r is greater than the number of Turing
machines with at most N states.)
The program then runs all Turing machines with at most N
states in parallel for at least t+1 steps. It looks for the
lexicographically least string of length r which did not appear as the
terminal output of any such machine, and writes this string as its
output. This completes our sketch of the construction of M_x with the
stated properties.
As ever,
Bob Solovay
∂16-Aug-88 1047 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Problem: zeros of a function
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Aug 88 10:47:36 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA00465; Tue, 16 Aug 88 10:46:20 PDT
Message-Id: <8808161746.AA00465@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Tue, 16 Aug 88 10:46:44 PDT
Received: by Forsythe.Stanford.EDU; Tue, 16 Aug 88 10:46:36 PDT
Received: by BYUADMIN (Mailer X1.25) id 3987; Tue, 16 Aug 88 11:13:12 MDT
Date: Mon, 15 Aug 88 14:29:05 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Raymond S Brand <leah!rsb584%CSD1.MILW.WISC.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Raymond S Brand <leah!rsb584%CSD1.MILW.WISC.EDU@Forsythe.Stanford.EDU>
Subject: Problem: zeros of a function
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Some Notation First:
Notation Read As
x[n] "the N-th X" or "X sub N"
x~y "X raised to the Y power"
ABS(x) "the absolute value of X"
Problem Statement:
Need a method to find the zeros of the function:
f(t) = (w[1] + t * v[1]) ~ (e[1])
+ (w[2] + t * v[2]) ~ (e[2])
+ (w[3] + t * v[3]) ~ (e[3])
- 1
subject to the constraints:
e[i] > 0 for i equal to 1, 2 and 3
at least one e[i] > 1 where i can be 1, 2 or 3
at least one e[i] < 1 where i can be 1, 2 or 3
at least one v[i] > 0 where i can be 1, 2 or 3
at lease one v[i] < 0 where i can be 1, 2 or 3
in the interval:
t1 <= t <= t2
such that:
0 <= (w[i] + t1 * v[i]) <= 1 for i equal to 1, 2 and 3
0 <= (w[i] + t2 * v[i]) <= 1 for i equal to 1, 2 and 3
Note: such an interval may not exist for a particular problem.
Additional Requirements:
The method needs to be as fast as possible and not be machine specific.
The Big Picture:
The above problem is special case of finding all of the intersections
of a line (in parametric form) with a generalized super-ellipse of the
form
ABS(X) ~ (e[1]) + ABS(Y) ~ (e[2]) + ABS(Z) ~ (e[3]) = 1
The application for this is a ray-tracer intended to run on inexpensive
computer systems such as the Amiga, Mac, PC-AT clones, etc.
Raymond S. Brand rsbx@beowulf.uucp
3A Pinehurst Ave. rsb584@leah.albany.edu
Albany NY 12203 FidoNet 1:141/255 (518-489-8968)
(518)-482-8798 BBS: (518)-489-8986
∂16-Aug-88 1050 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu cutting bodies with planes
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Aug 88 10:49:53 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA00586; Tue, 16 Aug 88 10:48:42 PDT
Message-Id: <8808161748.AA00586@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Tue, 16 Aug 88 10:49:05 PDT
Received: by Forsythe.Stanford.EDU; Tue, 16 Aug 88 10:48:27 PDT
Received: by BYUADMIN (Mailer X1.25) id 3630; Tue, 16 Aug 88 11:08:29 MDT
Date: Mon, 15 Aug 88 14:16:34 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Bjorn Lisper <lisper-bjorn@YALE-BULLDOG.ARPA>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Bjorn Lisper <lisper-bjorn@YALE-BULLDOG.ARPA>
Subject: cutting bodies with planes
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
I would appreciate pointers, suggestions, references, algorithms etc. to the
following problem:
Given a body K in R~k. Find a k-1-hyperplane H that cuts K into K1 and K2
such that the k-1-volume of the intersection of H and K is minimized while
the k-volumes of K1 and K2 are equal.
k = 2 and 3 are cases of special interest.
What role does the representation of the body play from an algorithmic point
of view?
I suspect that this is a very hard problem to solve in general. Are there
approximation algorithms? What about convex bodies?
I cross-posted this to comp.graphics since it seems related to solid
modelling. I would appreciate if people who see it there would e-mail any
comments to me since I don't read that newsgroup.
Bjorn Lisper
ARPA: lisper-bjorn@cs.yale.edu
UUCP: {decvax,ucbvax,harvard,cmcl2,...}!yale!lisper-bjorn
BITNET: lisper@yalecs
∂16-Aug-88 1050 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu 12th Columbia University Theory Day
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Aug 88 10:50:21 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA00593; Tue, 16 Aug 88 10:48:46 PDT
Message-Id: <8808161748.AA00593@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Tue, 16 Aug 88 10:49:10 PDT
Received: by Forsythe.Stanford.EDU; Tue, 16 Aug 88 10:48:33 PDT
Received: by BYUADMIN (Mailer X1.25) id 3875; Tue, 16 Aug 88 11:11:34 MDT
Date: Mon, 15 Aug 88 14:23:15 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Zvi Galil <GALIL%CS.COLUMBIA.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Zvi Galil <GALIL%CS.COLUMBIA.EDU@Forsythe.Stanford.EDU>
Subject: 12th Columbia University Theory Day
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
THE 12TH THEORY DAY
at Columbia University
SPONSORED BY THE DEPARTMENT OF COMPUTER SCIENCE
FRIDAY, SEPTEMBER 23, 1988
10:00 PROFESSOR LESLIE G. VALIANT
Harvard University
FUNCTIONALITY IN NEURAL NETS
11:00 PROFESSOR RICHARD J. LIPTON
Princeton University
P-RAM: A NEW SCALABLE IMPLEMENTATION
2:00 PROFESSOR JIAWEI HONG
Beijing Computer Institute and
University of Massachusetts
NEW DEVELOPMENTS ON PROVING BY EXAMPLES
3:00 PROFESSOR NEIL IMMERMAN
Yale University
DESCRIPTIVE AND COMPUTATIONAL COMPLEXITY
Coffee will be available at 9:30 am.
All lectures will be in the Kellogg Conference Center on the fifteenth
floor of the International Affairs Building, 118th Street and
Amsterdam Avenue.
The lectures are free and open to the public.
Call (212) 280-2736 or (212) 854-2736 for more information.
Theory Day is supported in part by a grant from the National Science
Foundation.
-------
∂16-Aug-88 1050 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Application of Splay Trees to Data Compression
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Aug 88 10:50:18 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA00591; Tue, 16 Aug 88 10:48:44 PDT
Message-Id: <8808161748.AA00591@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Tue, 16 Aug 88 10:49:06 PDT
Received: by Forsythe.Stanford.EDU; Tue, 16 Aug 88 10:48:29 PDT
Received: by BYUADMIN (Mailer X1.25) id 3733; Tue, 16 Aug 88 11:09:36 MDT
Date: Mon, 15 Aug 88 14:20:50 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Douglas Jones <jones%HERKY.CS.UIOWA.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Douglas Jones <jones%HERKY.CS.UIOWA.EDU@Forsythe.Stanford.EDU>
Subject: Application of Splay Trees to Data Compression
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Anyone interested in C source code for a UNIX utility using the prefix code
compression and encryption algorithm I described in the August '88 issue of
Communications of the ACM should send me mail with their network address and
postal address.
The utility is patterned after the BSD UNIX compress utility (Ziv Lempel),
and when allowed to use about 100 states in its Markov model, it compresses
about as well (sometimes better, sometimes worse).
The utility was written by a high-school student working under my direction
this summer, and he has decided to restrict commercial distribution, while
encouraging research use of the software. Open questions we would particularly
like to see answered are:
1) We used a stupid Markov model which knows nothing of the source. Is there
an adaptive (or better, locally adaptive) Markov model which is equally
computationally trivial but allows better advantage to be taken of the
source statistics for any particular message?
2) How secure is the use of this algorithm for encryption?
3) How does the security of the algorithm vary as a function of the number
letters in the key string used to permute the splay tree, assuming that
a Markov model is not used (that is, the number of states is 1).
4) Were we right in guessing that compressing a few characters of random data
at the head of the message would make known-text attacks more difficult?
5) When used for encryption, if the length of the key string used to permute
the splay trees is fixed, does adding states to the Markov model make
the encryption less secure? We suspect so, so we made the default number
of states 1 in the presence of a key.
Douglas Jones
Department of Computer Science
University of Iowa
Iowa City, IA 52242
jones@herky.cs.uiowa.edu
∂16-Aug-88 1154 GILBERTSON@Score.Stanford.EDU MJH Carpet Cleaning Tonite
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Aug 88 11:54:43 PDT
Date: Tue 16 Aug 88 11:46:26-PDT
From: Edith Gilbertson <GILBERTSON@Score.Stanford.EDU>
Subject: MJH Carpet Cleaning Tonite
To: CSD-List@Score.Stanford.EDU
cc: Gilbertson@Score.Stanford.EDU
Message-ID: <12422947078.13.GILBERTSON@Score.Stanford.EDU>
TONITE **TIS** TH'NITE
For The THIRD and FOURTH FLOORS*****
The carpets in Margaret Jacks Hall - Bldg 460 - will be cleaned on
August 16 and 17 at 4 pm.
McNevin Cleaning Specialists will begin on the 4th and 3rd floors
on Tuesday, August 16 at 4pm. They will shampoo the 2nd floor carpet
and the 040 rooms in the basement on Wednesday, August 17 at 4pm
and into the evening.
McNevin's plans to do individual offices - around the bookcases and
heavy pieces of furniture and under the desks. Please pick up boxes
and miscellaneous items and place them out of the way so they can
reach more area in your office.
If you do not want your office cleaned, let me know and place
a large sign on your door on August 16.
Thank you for your cooperation,
-Edie
-------
←
-------
∂17-Aug-88 1021 GILBERTSON@Score.Stanford.EDU BLDG 460 CARPET CLEANING *FINISHING*
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Aug 88 10:21:17 PDT
Date: Wed 17 Aug 88 10:09:42-PDT
From: Edith Gilbertson <GILBERTSON@Score.Stanford.EDU>
Subject: BLDG 460 CARPET CLEANING *FINISHING*
To: CSD-LIST@Score.Stanford.EDU
cc: GILBERTSON@Score.Stanford.EDU
Message-ID: <12423191612.33.GILBERTSON@Score.Stanford.EDU>
THEY'RE FINISHING UP TONITE*****
ON THE SECOND FLOOR AND BASEMENT*****
The carpets in Margaret Jacks Hall will be cleaned on August 16
and 17 at 4 pm.
McNevin Cleaning Specialists will begin on the 4th and 3rd floors
on Tuesday, August 16 at 4pm. They will shampoo the 2nd floor carpet
and the 040 rooms in the basement on Wednesday, August 17 at 4pm
and into the evening.
McNevin's plans to do individual offices - around the bookcases and
heavy pieces of furniture and under the desks. Please pick up boxes
and miscellaneous items and place them out of the way so they can
reach more area in your office.
If you do not want your office cleaned, let me know and place
a large sign on your door on August 16.
Thank you for your cooperation,
-Edie
-------
←
-------
∂17-Aug-88 1134 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu TCS geneology
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Aug 88 11:34:08 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA16134; Wed, 17 Aug 88 11:32:37 PDT
Message-Id: <8808171832.AA16134@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Wed, 17 Aug 88 11:33:00 PDT
Received: by Forsythe.Stanford.EDU; Wed, 17 Aug 88 11:33:59 PDT
Received: by BYUADMIN (Mailer X1.25) id 5691; Wed, 17 Aug 88 12:31:43 MDT
Date: Wed, 17 Aug 88 13:25:56 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Ian Parberry <ian%PSUVAXS.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Ian Parberry <ian%PSUVAXS.BITNET@forsythe.stanford.edu>
Subject: TCS geneology
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
In my call for updates to the TCS geneology, I paraphrased the entry
guidelines from David Johnson's original article.
> (A) Ph. D.'s who
> (1) have written a significant paper in theoretical computer science
> (in a refereed theoretical computer science journal or conference).
> (2) regularly attend STOC/FOCS conferences.
> (B) Advisor of a member of (A).
> (C) Famous person from another field (computer science, mathematics, physics,
> politics etc.) who has an ancestor who has a descendant in (A).
> (D) All of the people whose inclusion links (C) to (A).
Criterion (A)(2) has provoked some comment. Please note that it is NOT
conjunctive with (A)(1); all of the above are disjunctive. Also,
please note that it is NOT restricted to STOC/FOCS. Any theory
conference will do. I apologize if I have inadvertantly alienated
any member of the theory community.
The volume of responses prevents me from acknowledging each one
personally. I thank those who have already responded. I would
be grateful if those who sent incomplete information about new entries
(we need the adviser's name, the name of the university and date of
graduation) could fill in the missing blanks (I have tried sending
email to all concerned, but some of it got bounced for inexplicable
reasons).
Thanks,
Ian.
∂17-Aug-88 1344 @polya.Stanford.EDU:ARK@SAIL.Stanford.EDU Adv. Pgm.: Int. Symp. on Parallel and Distrib Systems, Dec 5-7, 88
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Aug 88 13:44:38 PDT
Received: from Sail.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA13129; Mon, 15 Aug 88 08:58:52 PDT
Message-Id: <kSWiF@SAIL.Stanford.EDU>
Date: 15 Aug 88 0859 PDT
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Adv. Pgm.: Int. Symp. on Parallel and Distrib Systems, Dec 5-7, 88
To: CS545-PEOPLE@SRI.COM, NAIL@Polya.Stanford.EDU
Cc: sjajodia@NOTE.NSF.GOV
ADVANCE PROGRAM
INTERNATIONAL SYMPOSIUM ON DATABASES IN
PARALLEL AND DISTRIBUTED SYSTEMS
December 5-7, 1988
Austin, Texas
Sponsored by: IEEE CS Technical Committee on Data Engineering
ACM SIG on Computer Architecture
=====================================================================
December 5, 1st Day
2 Tutorials 8:30 - 12:00
Opening Remarks
1:00 - 1:15 Joe Urban - University of Miami, Florida
1:15 - 1:30 Won Kim, MCC
Keynote Address
1:30 - 2:15 J.C. Browne - University of Texas at Austin
Session 1 2:30 - 3:45 Object-Oriented Systems
Chair: Gerald Karam - Carleton University
"The Relation between Problems in Large-Scale Concurrent Systems and
Distributed Databases (invited paper)"
Gul Agha - Yale University
"Writing Reliable Servers: Design and Implementation
in Avalon/C++
Richard Allen Lerner - Carnegie Mellon University
"Performance Modeling of Distributed Object-Oriented
Database Systems"
Jeffrey A. Brumfield - University of Texas at Austin
Janet Miller, Hong-Tai Chou - MCC
Break
Session 2 4:00 - 5:30 Logic-Based Systems
Chair: Ravi Krishnamurthy - MCC
"Exploiting Concurrency in a DBMS Implementation
for Production Systems"
Louiqa Raschid, Timos Sellis,
Chih-Chen Lin - University of Maryland
"Sharing the Load of Logic-Program Evaluation"
Ouri Wolfson - The Techniion-Israel Institute
of Technology
"Multiprocessor Transitive Closure Algorithms"
Rakesh Agrawal, H. V. Jagadish - AT&T Bell Laboratories
Reception 6:00 - 9:00
December 6, 2nd Day
Session 3 9:00 - 10:30 Parallel Database Systems
Chair: Rakesh Agrawal - AT&T Bell Laboratories
"Parallelism in Bubba (invited paper),"
Haran Boral - MCC
"Parallelizing FAD, a Database Programming Language:
Brian Hart, Scott Danforth, Patrick Valduriez - MCC
"JAS: A Parallel VLSI Architecture for Unformatted
Data Processing"
K.C. Lee, O. Frieder, V. Mak - Bell Communications
Research
Break
Session 4 11:00 - 12:30 Parallel Join
Chair: Anil Nigam - IBM Thomas J. Watson Lab.
"Parallel Join Algorithms on a Network of Workstations"
Xiao Wang, W.S. Luk - Simon Fraser University
"A Robust Protocol for Parallel Join Operations
in Distributed Data Bases"
S. Bandyopadhyay, A. Sengupta - University of Windsor
"Effect of Skew on Join Performance in Parallel
Architectures"
M. Seetha Lakshmi, Philip S. Yu - IBM Thomas J. Watson Lab.
Session 5 2:00 - 3:30
Panel: chair: John Carlis - University of Minnesota
"Parallelism in Databases: What, Why, and Whither"
Break
Session 6 4:00 - 5:30 Distributed Query Processing
Chair: Hong-Tai Chou - MCC
"A Case Study for Distributed Query Processing"
P. Agrawal, D. Bitton, K. Guh, C. Liu,
C. Yu - University of Illinois at Chicago
"Parallelism in Processing Queries on Complex
Objects"
T. Harder, H. Schoning, A. Sikeler - University
Kaiserslautern
"Heuristic Algorithms for Distributed Query
Processing"
P. Bodorik - Technical University of Nova Scotia
J.S. Riordon - Carleton University
Reception 6:00 - 9:00
December 7, 3rd Day
Session 7 9:00 - 10:30 Transaction Processing
Chair: Sunil Sarin - Computer Corp. of America
"Note Autonomy in Distributed Systems (invited paper),"
Hector Garcia-Molina, Boris Kogan - Princeton University
"Performance Evaluation of Global Reading of
Entire Databases"
Calton Pu, Christine H. Hong, Jae M. Wha -
Columbia University
"Multiprocessor Main Memory Transaction Processing"
Kai Li, Jeffrey F. Naughton - Princeton University
Break
Session 8 11:00 - 12:30 Distributed Databases
Chair: Ophir Frieder - Bell Comm. Res.
"VIP-MDBS: A Logic Multidatabase System"
Eva Kuhn, Thomas Ludwig - Technische Universitat
Wien, Austria
"Integrating Relational Databases with Support
for Updates"
M. Samy Gamal-Edin - Clarkson University
Gomer Thomas - Bell Communications Research
Ramez Elmasri - University of Houston
"Robust Transaction Routing in Distributed
Database Systems"
Yann-Hang Lee, Philip S. Yu - IBM Thomas J. Watson Lab.
===========================================================
Tutorial #1: Parallel Computing and Database Management
Instructor: Bruce K. Hilyer, AT&T Bell Labs
============================================================
Tutorial #2: Integrating Heterogeneous Distributed Databases:
Requirements, Concepts, and Solutions
Instructors: Ahmed K. Elmagarmid, Purdue U. and
Amith P. Sheth, UNISYS
===============================================================
For registration information, send a message to Sushil Jajodia
at sjajodia@note.nsf.gov.
∂18-Aug-88 1150 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Logics in Computer Science Proceedings
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Aug 88 11:50:37 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA04645; Thu, 18 Aug 88 11:48:59 PDT
Message-Id: <8808181848.AA04645@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Thu, 18 Aug 88 11:49:20 PDT
Received: by Forsythe.Stanford.EDU; Thu, 18 Aug 88 11:50:07 PDT
Received: by UWAVM (Mailer X1.24) id 2037; Thu, 18 Aug 88 11:46:51 PDT
Date: Thu, 18 Aug 88 13:40:08 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
George Cleland <glc%LFCS.ED.AC.UK@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: George Cleland <glc%LFCS.ED.AC.UK@Forsythe.Stanford.EDU>
Subject: Logics in Computer Science Proceedings
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
We have a small number of copies of the proceedings of the LICS
Symposium held in Edinburgh 5-8 July this year. (436 pages)
They are available for 20 pounds Sterling or 35 US dollars each, including
airmail postage anywhere in the world.
Requests, including payment should be sent to:
Monika Lekuse
Laboratory for Foundadtions of Computer Science
Department of Computer Science
University of Edinburgh
The King's Buildings
Edinburgh EH9 3JZ
United Kingdom
They will be issued on a first come first served basis.
George Cleland
Local Arrangements, LICS '88
∂19-Aug-88 1210 X3J13-mailer Virginia and Hawaii X3J13 meetings
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Aug 88 12:10:21 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA04379g; Fri, 19 Aug 88 11:10:09 PST
Received: by challenger id AA12057g; Fri, 19 Aug 88 12:08:20 PDT
Date: Fri, 19 Aug 88 12:08:20 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8808191908.AA12057@challenger>
To: x3j13@sail.stanford.edu
Cc: jlz@lucid.com
Subject: Virginia and Hawaii X3J13 meetings
Date: 17 Aug 1988 21:02-EDT
Sender: MATHIS@A.ISI.EDU
The next meeting of X3J13 will be held October 10-13, 1988, in Fairfax,
Virginia, at the Contel Technology Center at 12015 Lee Jackson Highway (US
Route 50). Monday (October 10) will be used for subcommittee meetings and
Tuesday and Wednesday (October 11 and 12) will be used for the general
meeting. If necessary Thursday can also be used for subcommittee meetings.
The Contel Technology Center is located in the same building with Contel
Federal Systems across the parking lot from Fair Oaks Shopping Center. On the
other side of the shopping Center is the Holiday Inn Fair Oaks (11787 Lee
Jackson Highway, 703-352-2525) where some rooms are being held for our group.
These facilities are located at the intersection of US Route 50 and Interstate
66. This is outside the beltway two exits further west along I-66 from where
the Metro Orange line ends. Coming from National Airport, one would go by the
Pentagon along 110 through Rosslyn to go west on I-66. From Dulles airport,
take the first exit south onto Route 28 and then east on Route 50. The cab
fare from Dulles should be about $20 and from National about $30. There is
also bus service to Fair Oaks Shopping Center.
To register contact the hotel directly (and memtion Contel and this group) and
Jan Zubkoff at Lucid. The meeting fee will be $50 (make checks payable to
Lucid). For special local questions, contact Bob Mathis. We need an
indication, as soon as possible, about attendance and subcommittee meeting
needs.
The agenda of this meeting should be quite full. We expect final (or almost
final) reports from ALL subcommittees. The CLOS committee is working toward
presenting chapter 3. The clean-up committee will have a number of issues to
review. The editorial committee has the beginnings of a draft. The compiler,
character, and iteration committees should also have reports. Will there be
any others? From the subcommittee leaders, I need any documents they want
distributed, their subcommittee meeting plans, their expectations about full
X3J13 actions, and their anticipated time on the agenda.
The meeting after next will be held January 16-18, 1989, in Kauai, Hawaii. Jan
Zubkoff will be handling the arrangements and needs an indication of
anticipated attendance as soon as possible. We are not anticipating
subcommittee meetings there because we want to have final resolution of any
remaining issues, not just progress reports from the subcommittees. The
subcommittees may need to communicate between the Fairfax and Hawaii meetings.
For the January meeting agenda, it is anticipated that there will be a full
day on final clean-ups, a half day on final CLOS issues, a half day for other
yet-to-be-resolved issues from other sub-committees, and a full day on an
initial review of the draft of the standard.
*******************************************************************************
X3J13/ISO Meeting
X3J13: 1/16/89 - 1/18/89
ISO: 1/19/89 - 1/20/89
Kauai, Hawaii
Committee Meeting:
Dates: 1/16/89 - 1/18/89
Time: 9:00 - 5:00
City: Kapaa, Kauai, Hawaii
Place: Sheraton Coconut Beach Hotel
REGISTRATION FEE: $75 Payable to: LUCID, Inc.
ISO Meeting:
Dates: 1/19/89 - 1/20/89
Hotel Accomodations:
Hotel: Sheraton Coconut Beach Hotel
Address: Coconut Plantation
Phone: 808/822-3455
Directions from airport:
Turn right onto route 56 north (Kuhio Highway)
Look for the 7 mile marker and take next right (can see hotel from the
road but it is not on the main road)
Rate: $80/night
Mention: "X3J13 Standards Committee" for rate
Group Luau:
Place: Shearton Coconut Grove
Date: 1/17/89
Time: TBA
For further information contact:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
jlz@lucid.com
(415) 329-8400
!
X3J13/ISO January Meeting Registration Form
Please include check for $75.00 payable to Lucid mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
jlz@lucid.com
Name: _____________________________________________________________
Institution: ______________________________________________________
Net-Address: ______________________________________________________
Phone: ____________________________________________________________
Attend X3J13 _________ Attend ISO _________
Lunch 1/16: _________ yes _______ no
Lunch 1/17: _________ yes _______ no
Lunch 1/18: _________ yes _______ no
Luau 1/17 $38.50: _________ yes _______ no
∂22-Aug-88 0814 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu call for papers -- workshop on database programming languages
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Aug 88 08:14:30 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA10250; Mon, 22 Aug 88 08:13:18 PDT
Message-Id: <8808221513.AA10250@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Mon, 22 Aug 88 08:13:36 PDT
Received: by Forsythe.Stanford.EDU; Mon, 22 Aug 88 08:14:22 PDT
Received: by UWAVM (Mailer X1.24) id 7316; Mon, 22 Aug 88 08:10:41 PDT
Date: Mon, 22 Aug 88 10:00:05 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Richard Hull <hull%pollux.usc.edu%OBERON.USC.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Richard Hull <hull%pollux.usc.edu%OBERON.USC.EDU@Forsythe.Stanford.EDU>
Subject: call for papers -- workshop on database programming languages
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
Call for Papers
Second International Workshop on
Database Programming Languages
June 4 - 7, 1989
on the Oregon coast
The second International Workshop on Database Programming Languages
will take place on the Oregon coast, from June 4 - 7, 1989. These
dates immediately follow the ACM SIGMOD Intl. Conf. on Management of
Data which is being held in Portland, Oregon, from May 31 to June 2.
The workshop will continue in the directions and style of its
predecessor, which was held in Roscoff, France, in September, 1987.
The meeting will be small and informal, providing forums for both
prepared presentations and informal panels and discussions.
Participation in the workshop is by invitation of the program
committee, and will be restricted primarily to authors of accepted
papers.
The workshop will focus on the development of new programming
languages and environments for databases and data-intensive
applications. Topics include, but are not limited to:
data models deductive capabilities
types and type inference compilation
inheritance versions
persistence implementation issues
object-oriented approaches applications
Authors are invited to submit 9 copies of a technical summary of a
prospective paper for the workshop by January 13, 1989 to either
Richard Hull or Ron Morrison
Computer Science Department Department of Computational Science
University of Southern California University of St. Andrews
Los Angeles, CA 90089-0782 St. Andrews KY16 8SX
USA Scotland
The focus of the workshop is on emerging approaches and technologies;
the committee will consider papers describing preliminary as well as
completed research. The technical summary should be brief and not
exceed 10 double-spaced pages. Authors will be notified of the
acceptance or rejection of their papers by March 10, 1989. Full
versions of the accepted papers must be received in camera ready form
by April 14, 1989.
Workshop proceedings will be available at the workshop. Also, revised
versions of the accepted papers will be published by Morgan-Kaufmann,
Inc.
Program Committee Co-Chairs Program Committee
Richard Hull Antonio Albano (Universitadi Udine)
+01 (213) 743-5501 Francois Bancilhon (INRIA/Altair)
hull@cse.usc.edu Peter Buneman (Univ. of Pennsylvania)
Ron Morrison Luca Cardelli (DEC)
+44 334 76161 ext. 8121 Richard Hull (USC)
ron\%uk.ac.st-and.cs@ukc Ron Morrison (Univ. of St. Andrews)
David Stemple Craig Schaffert (DEC)
+01 (413) 545-2372 Joachim Schmidt (Univ. Frankfurt)
stemple@cs.umass.edu David Stemple (Univ. of Massachusetts)
Local Arrangements
David Maier
Computer Science and Engineering Treasurer
Oregon Graduate Center Dean Jacobs (USC)
19600 N.W. Von Neumann Drive
Beaverton, OR 97006-1999
+01 (503) 690-1154
maier@ogcvax.ogc.edu
∂22-Aug-88 0817 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Papers: MFCS'89
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Aug 88 08:17:30 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA10334; Mon, 22 Aug 88 08:16:20 PDT
Message-Id: <8808221516.AA10334@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Mon, 22 Aug 88 08:16:39 PDT
Received: by Forsythe.Stanford.EDU; Mon, 22 Aug 88 08:17:23 PDT
Received: by UWAVM (Mailer X1.24) id 7369; Mon, 22 Aug 88 08:11:03 PDT
Date: Mon, 22 Aug 88 10:03:29 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Peter Mosses <pdm%DAIMI.DK@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Peter Mosses <pdm%DAIMI.DK@Forsythe.Stanford.EDU>
Subject: Call for Papers: MFCS'89
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
--------------------------------------------------------------------------
CALL FOR PAPERS
Mathematical Foundations of Computer Science (MFCS)
Fourteenth International Symposium
August 28 -- September 1, 1989, Rytro, near Cracow, POLAND
This international symposium is the fourteenth in the series of annual
MFCS symposia organized alternately in Poland and Czechoslovakia. The
symposium is being organized by the Institute of Informatics, University
of Warsaw.
The purpose of the meeting is to encourage research in theoretical
computer science and to bring together specialists from various countries.
Principal areas of interest: logics of programs, concurrency, deductive
databases, software specification and validation, computational
complexity. This is not intended to be an exhaustive list.
The scientific program includes invited lectures covering areas of current
interest, and submitted papers describing original research.
INSTRUCTIONS FOR AUTHORS: Authors are invited to submit five copies of a
full draft paper or extended abstract in English before JANUARY 15, 1989,
to the Chairman of the Program Committee:
Grazyna Mirkowska
MFCS'89
Institute of Informatics
University of Warsaw
00--901 Warsaw, PKiN
Poland
tel. ++48-22-268-258, telex 815591 infuw pl
Authors will be notified of acceptance or rejection by APRIL 1, 1989.
Deadline for final text: MAY 15, 1989
Please use the attached Reply Card as preliminary information to the
organizers and return it at your earliest convenience. The number of
participants is limited.
Program Committee: A. Arnold (Bordeaux), J. de Bakker (Amsterdam),
A. Blikle (Warsaw), P. van Emde Boas (Amsterdam), A. P. Ershov
(Novosibirsk), J. Gruska (Bratislava), H. Langmaack (Kiel),
A. Maggiolo-Schettini (Pisa), G. Mirkowska (Warsaw), P. Mosses (Aarhus),
M. Protasi (Roma), A. Salwicki (Warsaw), and others yet to be confirmed.
Organizing Committee: K. Diks, M. Grabowski, A. Kreczmar, G. Mirkowska,
A. Szalas.
Address of Conference Bureau:
Institute of Informatics
University of Warsaw
00--901 Warsaw, PKiN box 1210
POLAND
!
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
REPLY CARD MFCS'89
Name __________________________________________________ Ms/Mr
Address __________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Yes No
( ) ( ) I wish to attend the symposium. Please send me
further details and the registration form.
( ) ( ) I wish to submit a paper. Provisional title/subject:
_____________________________________________________
I expect to be accompanied by ___ persons.
------------------------------------------------------------------------
-----
Peter Mosses pdm@daimi.DK
----------------------------------------------------------------------
[ Computer Science Department * Aarhus University * Aarhus * Denmark ]
----------------------------------------------------------------------
∂22-Aug-88 1630 DELAGI@SUMEX-AIM.Stanford.EDU [Lori S. Grob <grob@cmcl2.NYU.EDU>:]
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Aug 88 16:30:14 PDT
Date: Mon, 22 Aug 88 16:22:58 PDT
From: Bruce A. Delagi <DELAGI@SUMEX-AIM.Stanford.EDU>
Subject: [Lori S. Grob <grob@cmcl2.NYU.EDU>:]
To: aap@SUMEX-AIM.Stanford.EDU
Message-ID: <12424570283.55.DELAGI@SUMEX-AIM.Stanford.EDU>
for references..../b
---------------
Return-Path: <fpst@hubcap.clemson.edu>
Received: from RELAY.CS.NET by SUMEX-AIM.Stanford.EDU with TCP; Thu, 18 Aug 88 09:57:16 PDT
Received: from hubcap.clemson.edu by RELAY.CS.NET id aa19953;
18 Aug 88 11:27 EDT
Received: by hubcap.clemson.edu; Thu, 18 Aug 88 11:23:31 edt
Date: Thu, 18 Aug 88 11:23:31 edt
Message-Id: <8808181523.AA25445@hubcap.clemson.edu>
To: DELAGI%SUMEX-AIM.Stanford.EDU@RELAY.CS.NET,
coraki!pratt%Sun.COM@RELAY.CS.NET, cvb%daresbury.ac.uk@RELAY.CS.NET,
develo%waikato.ac.nz@RELAY.CS.NET, gopalakr%enuxha.asu.edu@RELAY.CS.NET,
hcube-users%hamlet.caltech.edu@RELAY.CS.NET,
hcube-users%mtu.edu@RELAY.CS.NET,
mcdonaldi%comsci.ua.oz%uunet.UU.NET@RELAY.CS.NET,
prasanna%usc-cse.usc.edu@RELAY.CS.NET,
scherrer%lovada.dec.com@RELAY.CS.NET
Newsgroup: comp.parallel
From: Lori S. Grob <grob@cmcl2.NYU.EDU>
Subject: UNIX ON SUPERCOMPUTERS WORKSHOP
Approved: parallel@hubcap.clemson.edu
UNIX ON SUPERCOMPUTERS WORKSHOP
A large number of supercomputers are now or will in the
future be running Unix as their primary operating system.
This is the first workshop to consider the general problems
of running Unix on supercomputers, and will cover topics
both practical and abstract. Some of the topics that will
be covered are
o Performance
o Parallelism
o Scheduling and Load Balancing
o Storage Management
o Processes and Process Management
o Experiences
The workshop sessions will include both full-length papers
and short presentations, and there will be works in progress
sessions. Works in progress presentation slots will be
available at the workshop on a first come, first served
basis. Proceedings will be provided to registered attendees
at the workshop.
In addition to the regular sessions, there will be a trip to
the Pittsburgh Supercomputing Center and Westinghouse Energy
Center facilities. Housed in the same building, this is one
of the largest privately-owned computing centers in the
world. A reception will be held in conjunction with the
visit. There will also be a no-host reception Sunday even-
ing preceding the workshop.
WORKSHOP EVENT SCHEDULE
SUNDAY EVENING, September 25
4:00pm - 9:00pm No host reception and registration
MONDAY, September 26
9:00am - 5:00pm Workshop sessions
7:00pm - 9:00pm Reception at Pittsburgh Supercomputing &
Westinghouse Energy Center
TUESDAY, September 27
9:00am - 5:00pm Workshop sessions
P R E L I M I N A R Y S C H E D U L E O F S P E A K E R S
(Subject to Change)
Performance
-----------
Kenneth Bobey, Myrias Research Corporation.
"Monitoring Program Performance on Large Parallel Systems"
Eugene Miya, NASA Ames Research Center.
"Some Observations on Computer Performance Characterization"
John Renwick, Cray Research, Inc..
"High-speed networking with Supercomputers"
(short presentation)
Parallelism
-----------
Brian Baird, Myrias Research Corporation.
"Distributed UNIX Services in a Massively Parallel Supercomputer"
Ray Bryant, et al., IBM T.J. Watson Research Center.
"The RP3 Parallel Computing Environment"
Brewster Kahle and Bill Nesheim, Thinking Machines.
"The Use of Unix in the Connection Machine System"
Traian Muntean, University of Grenoble.
"UNIX* on Transputers* based supercomputers"
Scheduling and Load Balancing
---------- --- --------------
Martin Fouts, NASA Ames Research Center.
"Multitasking under UniCos: Experiences with the Cray 2"
Ralph Knag, AT&T Bell Laboratories.
"The Unicos Fair Share Scheduler"
(short presentation)
Storage Management
------- ----------
Patrick Clancy, Multiflow Computer.
"Virtual Memory Extensions in TRACE/UNIX"
Jan Edler, Jim Lipkis, and Edith Schonberg, Ultracomputer Research Laboratory.
"Memory Management in Symunix II"
E.C. Pariser, AT&T Bell Labs.
"Static and Dynamic Reduction of Memory Requirements on the
Cray X-MP"
Mike Muuss, BRL, Terry Slattery, USNA, and Don Merritt, BRL.
"BUMP - The BRL/USNA Migration Project"
Alan Poston, GE Aerospace, NASA Ames Research Center.
"A High Performance File System for UNIX"
Douglas E. Engert, National Laboratory.
"Attaching IBM Disks Directly to a Cray X-MP"
(short presentation)
Processes and Process Management
--------- --- ------- ----------
Jim Lipkis, Jan Edler, and Edith Schonberg, NYU Ultracomputer Project.
"Process Management Extensions at the Ultracomputer Project"
Piyush Mehrotra, Purdue University.
"Microthreads: Featherweight Processes in C"
Dennis Ritchie, AT&T Bell Laboratories.
"A Guest Facility for Unicos"
Experiences (all short presentations)
-------------------------------------
H. Stephen Anderson, Ohio Supercomputer Graphics Project.
"Distributed Supercomputer Graphics Using Unix Tools"
Jonathan Brown, Lawrence Livermore National Laboratory.
"The CTSS/Posix Project"
Robert M. Panoff, Department of Physics and Astronomy.
"Real Productivity for Real Science Without Real UNIX"
Satoshi Sekiguchi, Hiroyuki Kusumoto, and Akio Kokubu, Electrotechnical
Laboratory.
"A Design for Supercomputing Environment at the Tsukuba
Research Center of MITI"
Cheryl Stewart, Cornell Mathematical Sciences Institute.
"Numerical Interprocess Communication Protocol"
Kevin Wohlever, Cray Research, Inc.
"Unicos System Administration at the Ohio Supercomputer
Center - Tuning Considerations"
W O R K S H O P R E G I S T R A T I O N I N F O R M A T I O N
You MUST register in advance to attend this limited
enrollment workshop. Register early as space is available
on a first-come, first-served basis.
REGISTRATION FEE............. $200.00
REGISTRATION DEADLINE........ September 19, 1988
You may pay by check (MAKE CHECK PAYABLE TO USENIX CONFER-
ENCE) or use your VISA, MasterCard, or American Express
charge card to pay your registration fees. Payment MUST
accompany registration form. Purchase orders and vouchers
are not accepted.
R E F U N D C A N C E L L A T I O N P O L I C Y
If you must CANCEL, all refund requests must be in writing
and postmarked no later than September 19, 1988. Direct
your letter to the USENIX Conference Office.
H O T E L I N F O R M A T I O N
The workshop will be held at:
The Westin William Penn Hotel
530 William Penn Way
Pittsburgh, PA 15219
Telephone # (412) 281-7100
ROOM RATES: $85.00/night - Single or Double Occu-
pancy (Plus 9% city and state tax)
TO MAKE YOUR RESERVATION.......
Call the Hotel directly and ask for the Reservation Desk.
Tell reservations that you are a USENIX Conference atten-
dee to take advantage of our group rate. You may guaran-
tee your late arrival with a major credit card.
IMPORTANT: Room reservation deadline is September 6,
1988. Requests for reservations received after the dead-
line will be handled on a space and RATE available basis.
A I R P O R T T O H O T E L T R A N S P O R T A -
T I O N
The Airlines Transportation Company Bus at the Greater
Pittsburgh Airport provides shuttle service to the William
Penn Hotel. Due to construction, buses are only departing
from one area of the airport at this time. To catch the
bus, go right outside the U.S.Air baggage claim area
located on the lower level of the main terminal, or check
with the Airlines Transportation Company desk located near
the rental car agencies, to verify their next scheduled
departure. Buses run approximately every 20 - 30 minutes
at a cost of $8.00 one way.
Taxi service is available at an approximate cost of $25
one way.
FOR FURTHER CONFERENCE INFORMATION, PLEASE CONTACT:
USENIX Conference Office
P.O. Box 385
16951 Pacific Coast Hwy
Sunset Beach, CA 90742
Telephone (213) 592-1381, (213) 592-3243
Program Co-chairs:
Lori Grob Melinda Shore
NYU Ultracomputer Research Frederick Cancer Research
Lab Facility
715 Broadway, 10th Floor P.O. Box B, Building 430
New York, New York 10003 Frederick, MD 21701
(212) 998-3339 (301)698-5660
grob@lori.ultra.nyu.edu shore@ncifcrf.gov
or grob@nyu.edu
-------
∂23-Aug-88 1448 JONES@Score.Stanford.EDU Honor Code
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Aug 88 14:48:14 PDT
Date: Tue 23 Aug 88 14:48:29-PDT
From: H. Roy Jones <JONES@Score.Stanford.EDU>
Subject: Honor Code
To: faculty@Score.Stanford.EDU
Message-ID: <12424815227.24.JONES@Score.Stanford.EDU>
Over the last few months a number of possible honor code violations that
have not been prosecuted have been called to my attention. Because many
of these cases seemed open and shut I have set up a meeting with Sally
Cole, who is in charge of Judicial Affairs, to discuss the complexities
of the prosecution process. I hope that we will also be able to help
her understand more about the nature of computer science coursework.
The meeting is Thursday at 10:30 in Old Union.
Please let me know if you plan to attend.
Thanks,
Roy Jones
-------
∂23-Aug-88 2300 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu Re: Honor Code
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Aug 88 23:00:28 PDT
Received: from Pescadero by SCORE.STANFORD.EDU with TCP; Tue 23 Aug 88 23:00:31-PDT
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA24804; Tue, 23 Aug 88 22:59:52 PDT
Date: Tue, 23 Aug 88 22:59:52 PDT
From: "David Cheriton" <cheriton@pescadero.stanford.edu>
Message-Id: <8808240559.AA24804@Pescadero>
To: JONES@score.Stanford.EDU, faculty@score.Stanford.EDU
Subject: Re: Honor Code
In-Reply-To: <12424815227.24.JONES@Score.Stanford.EDU> from H. Roy Jones
<JONES@Score> on Tue 23 Aug 88 14:48:29-PDT
I think this would be a good topic for an early-in-the-quarter
faculty lunch as well, if she should be willing. I think we do need
to be prepared to enforce.
∂24-Aug-88 1202 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu International Symposium on Optimal Algorithms
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Aug 88 12:02:39 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA03937; Wed, 24 Aug 88 12:01:16 PDT
Message-Id: <8808241901.AA03937@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Wed, 24 Aug 88 12:01:33 PDT
Received: by Forsythe.Stanford.EDU; Wed, 24 Aug 88 12:02:18 PDT
Received: by UWAVM (Mailer X1.24) id 7216; Wed, 24 Aug 88 11:57:37 PDT
Date: Wed, 24 Aug 88 13:45:28 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Andrzej Lingas <ajl%IDA.LIU.SE@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Andrzej Lingas <ajl%IDA.LIU.SE@Forsythe.Stanford.EDU>
Subject: International Symposium on Optimal Algorithms
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
CALL FOR PAPERS
---------------
International Symposium on
OPTIMAL ALGORITHMS
May 29-June 2, 1989
Varna, Bulgaria
The International Symposium on optimal algorithms which is
organized by the Bulgarian Academy of Sciences is intended to provide
a forum for researchers in the area of the design and analysis of
algorithms. The symposium will be held in Varna, a nice resort at
the Black Sea.
Papers presenting original research in areas related to algorithmic
theory are being sought. Suggested areas include:
graph algorithms
sorting
data structures
computational geometry
parallel numerical and combinatorial algorithms
systolic arrays
complexity
Contributors are invited to submit 3 copies of a two-page camera-
ready abstract to:
Prof. B. Sendov
(International Symposium on Optimal Algorithms)
Center of Informatics and Computer Technology
Acad. G. Bonchev str. bl. 25-A
Sofia 1113, BULGARIA
(Phone +359-2 708494, tlx. 22056 KZIIT-BG)
Abstracts must arrive before February 15, 1989. Notification about
acceptance will be mailed by April 15, 1989. A collection of the
accepted abstracts will be available at the symposium and official
proceedings of refereed full length papers will be published
afterwards.
INVITED SPEAKERS (list not exhaustive):
F. Dehne (Carleton University, Ottawa, Canada)
J. Gilbert (Cornell University, Ithaca, USA)
A. Lingas (Linkoping University, Linkoping, Sweden)
J. Miklosko (Slovak Academy of Sciences, Bratislava, Czechoslovakia)
J. Reif (Duke University, Durham, USA)
A. Rosenberg (University of Massachusetts, Amherst, USA)
V. Voevodin (Academy of Sciences of USSR, Moscow, USSR)
ORGANIZING COMMITTEE
B. Sendov (Bulgarian Academy of Sciences), Chairman
B. Bojanov (University of Sofia)
H. Djidjev (Bulgarian Academy of Sciences)
R. Lazarov (Bulgarian Academy of Sciences)
-------
∂26-Aug-88 0923 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Theory Net archives
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Aug 88 09:23:22 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA15085; Fri, 26 Aug 88 09:22:03 PDT
Message-Id: <8808261622.AA15085@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Fri, 26 Aug 88 09:22:19 PDT
Received: by Forsythe.Stanford.EDU; Fri, 26 Aug 88 09:23:05 PDT
Received: by BYUADMIN (Mailer X1.25) id 4399; Fri, 26 Aug 88 10:20:45 MDT
Date: Fri, 26 Aug 88 11:10:05 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Victor Miller -- moderator, Theory Net" <THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: "Victor Miller -- moderator, Theory Net" <THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu>
Subject: Theory Net archives
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
The server for Theory Net is now connected to the internet. This means that
archives of Theory Net are available for FTP. All of the archives have
names like THEORYNT.LOGyymm where yy is the last two digits of the year
and mm is the ordinal of the month. The FTP userid is ANONYMOUS with
password of GUEST. The directory the archives reside is called LISTARCH.
Victor
∂26-Aug-88 0932 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Theorynet archives and FTP
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Aug 88 09:32:10 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA15384; Fri, 26 Aug 88 09:30:58 PDT
Message-Id: <8808261630.AA15384@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Fri, 26 Aug 88 09:31:14 PDT
Received: by Forsythe.Stanford.EDU; Fri, 26 Aug 88 09:32:09 PDT
Received: by BYUADMIN (Mailer X1.25) id 4978; Fri, 26 Aug 88 10:29:34 MDT
Date: Fri, 26 Aug 88 11:24:38 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Victor Miller -- moderator, Theory Net" <THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: "Victor Miller -- moderator, Theory Net" <THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu>
Subject: Theorynet archives and FTP
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
I should have given the internet name of the host for archives, it is
VM1.NODAK.EDU. So to get archives do:
FTP VM1.NODAK.EDU
USERID ANONYMOUS
PASSWORD GUEST
CD LISTARCH
GET THEORYNT.LOG8808
(for example -- this would get august 1988 archives).
∂27-Aug-88 0935 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu 10th International Conference on Petri Nets
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Aug 88 09:34:54 PDT
Received: from Lindy.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA14822; Sat, 27 Aug 88 09:33:41 PDT
Message-Id: <8808271633.AA14822@polya.Stanford.EDU>
Received: by lindy.Stanford.EDU (4.0/4.7); Sat, 27 Aug 88 09:33:57 PDT
Received: by Forsythe.Stanford.EDU; Sat, 27 Aug 88 09:34:34 PDT
Received: by BYUADMIN (Mailer X1.25) id 8555; Sat, 27 Aug 88 10:31:39 MDT
Date: Sat, 27 Aug 88 10:39:43 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Eike Best <mcvax!unido!gmdzi!eike@UUNET.UU.NET>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Eike Best <mcvax!unido!gmdzi!eike@UUNET.UU.NET>
Subject: 10th International Conference on Petri Nets
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
----------------------------------------------------------------------
CALL FOR PAPERS
TENTH INTERNATIONAL CONFERENCE ON APPLICATION AND THEORY OF PETRI NETS
Wednesday 28 - Friday 30, June 1989
and
PETRI NETS TUTORIAL
Monday 26 - Tuesday 27, June 1989
BONN, FEDERAL REPUBLIC OF GERMANY
The Tenth Annual International Petri Net Conference will be organized by
the Gesellschaft fuer Mathematik und Datenverarbeitung (GMD),
the German National Research Center for Computer Science. Papers
presenting original contributions in any area of applications and theory
of Petri nets are sought. The language of the conference is English.
TOPICS
System design and verification using nets.
Causality/partial order theory of concurrency.
Analysis and synthesis, structure and behaviour of nets.
Net-based semantical, logical and algebraic calculi.
Higher-level net models.
Timed and stochastic nets.
Relationships between net theory and other approaches.
Symbolic net representations (graphical, textual, ...).
Computer tools.
Experience with using nets, case studies.
Educational issues.
Applications of nets to:
Office automation,
Flexible manufacturing systems,
Programming languages,
Protocols and interfaces,
Hardware structures,
Real-time systems,
Performance evaluation,
Operations research,
Embedded systems.
The conference takes place under the auspices of: AFCET SIG 'Systemes
Paralleles et Distribues' and CNRS-C3, AICA, BCS SIG 'Formal Aspects of
Computing Science', EATCS and GI SIG 'Petri Nets and Related System
Models'.
PAPERS
Authors are invited to submit an extended abstract (approx. 10 pages)
or a full draft paper (at most 30 pages). The title page must contain a
short abstract and a classification of the topics covered, preferrably
using the list of topics above. The paper or extended abstract must
clearly state the problem being addressed, the goal of the work, the
results achieved and the relation to other work.
TOOLS, POSTERS AND PROJECTS
The conference will also comprise:
An exhibition of computer tools for nets. Scheduled periods are set
aside during the tutorial and conference for tool demonstrations.
An exhibition of posters describing theoretical and practical results.
Posters are displayed throughout the conference with a scheduled period
for discussing them. Authors must submit a one page description of their
poster.
Short presentations of projects where nets are put into practice. This
section of the conference allows the presentation of experiences of
using nets in ongoing or completed projects. The presentation may be
supplemented by a brief report in the proceedings. Authors must submit a
2 to 4 page outline of the project.
SUBMISSIONS
All four kinds of submissions (10 copies) must be received by the
chairman of the program committee no later than January 15, 1989.
Authors should clearly indicate the kind(s) of submission intended.
Authors will be notified of acceptance/rejection by April 1, 1989. Final
papers are due by May 15, 1989. The page limit will be 20 pages for
papers and 10 pages for project presentations.
TUTORIAL
The tutorial will concentrate on the basic notions and fundamental
concepts from the broad spectrum of Petri nets.
PROGRAM COMMITTEE CHAIRMAN
Prof. Giorgio De Michelis
Universit'a degli Studi di Milano
Dipartimento di Scienze dell'Informazione
Via Moretto da Brescia, 9
I-20133 Milano, Italy
ORGANIZING COMMITTEE CHAIRMEN
Dr. W. Reisig, Dr. Klaus Voss
Gesellschaft fuer Mathematik
und Datenverarbeitung, GMD-F1.P
Postfach 12 40
D-5205 Sankt Augustin 1, FRG
PROGRAM COMMITTEE
G.F. Balbo, Italy
E. Best, FRG
J. Billington, Australia
W. Brauer, FRG
Ph. Chretienne, France
S. Kodama, Japan
M. Lindqvist, Finland
G. De Michelis, Italy (chairman)
T. Murata, USA
M. Nielsen, Denmark
G. Rozenberg, The Netherlands
M. Silva, Spain
D. Simpson, Great Britain
P. Starke, GDR
R. Valette, France
---------------------------------------------------------------------
∂28-Aug-88 1228 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU NSF waste
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Aug 88 12:28:39 PDT
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 28 Aug 88 12:26:44-PDT
Message-ID: <uZplr@SAIL.Stanford.EDU>
Date: 28 Aug 88 1226 PDT
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: NSF waste
To: faculty@SCORE.STANFORD.EDU
Perhaps many of you have received an NSF brochure
entitled "Special Initiative on Coordination Theory
and Technology". It solicits multi-investigator
proposals for up to $400,000. Of course, the money
for this means that there will be less for unsolicited
proposals unrestricted as to content.
I would have no idea what kinds of proposals are considered
appropriate for this program, and it seems ill-thought out.
I don't know how such programs come into existence, but I
guess it's boring for an NSF program manager to simply
send out for review and evaluate proposals, and programs
initiated within NSF are more fun to run. Perhaps some
scientific friends of the program manager held a conference
claiming a need for this and lobbied for it. I believe the
scientific and professional societies should take the
initiative in proposing that NSF devote only a small fraction
of its budget to "special initiatives" and the need for them
be evaluated very carefully.
∂28-Aug-88 1247 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU Special Initiative on Coordination Theory and Technology
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Aug 88 12:47:12 PDT
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 28 Aug 88 12:45:38-PDT
Message-ID: <uZqrC@SAIL.Stanford.EDU>
Date: 28 Aug 88 1244 PDT
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: Special Initiative on Coordination Theory and Technology
To: irosenberg@NOTE.NSF.GOV
CC: faculty@SCORE.STANFORD.EDU, reddy@FAS.RI.CMU.EDU
I received your four page announcement of this program and it filled
my heart with terror.
My first reaction was the following message sent to computer science
faculty at Stanford.
∂28-Aug-88 1226 JMC NSF waste To:faculty@SCORE.STANFORD.EDU
Perhaps many of you have received an NSF brochure
entitled "Special Initiative on Coordination Theory and
Technology". It solicits multi-investigator proposals
for up to $400,000. Of course, the money for this
means that there will be less for unsolicited proposals
unrestricted as to content.
I would have no idea what kinds of proposals
are considered appropriate for this program, and it
seems ill-thought out. I don't know how such programs
come into existence, but I guess it's boring for an NSF
program manager to simply send out for review and
evaluate proposals, and programs initiated within NSF
are more fun to run. Perhaps some scientific friends
of the program manager held a conference claiming a
need for this and lobbied for it. I believe the
scientific and professional societies should take the
initiative in proposing that NSF devote only a small
fraction of its budget to "special initiatives" and the
need for them be evaluated very carefully.
Perhaps I was hasty, and I see that one can apply to you directly
for more information. Therefore, I am requesting information
as follows.
1. What is the full justification for the program, i.e.
the document on which NSF management signed off?
2. What combination of NSF and outside initiative led
to the program?
3. What is the planned duration of the program and at
what level is it funded?
4. What other programs are being squeezed for its funding?
Please consider this a Freedom of Information Act request
if possible. If regulations don't permit this being considered
such a request, e.g. if some form must be filled out, please let me
know. Also if you think we could both be satisfied by something
less formal, I will consider withdrawing the formal aspect of
the request. If some information is available right away and other
information will take longer, please send the former first.
∂28-Aug-88 1446 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU previous message
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Aug 88 14:46:07 PDT
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 28 Aug 88 14:44:20-PDT
Message-ID: <uZrOA@SAIL.Stanford.EDU>
Date: 28 Aug 88 1412 PDT
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: previous message
To: faculty@SCORE.Stanford.EDU
It should have been addressed to lrosenberg@note.nsf.gov in case any
of you want to contact him directly. It was retransmitted to what is,
I hope, the correct address.
∂28-Aug-88 1642 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU qualification of previous message
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Aug 88 16:42:42 PDT
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 28 Aug 88 16:41:06-PDT
Message-ID: <uZtZG@SAIL.Stanford.EDU>
Date: 28 Aug 88 1640 PDT
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: qualification of previous message
To: lrosenberg@NOTE.NSF.GOV
CC: faculty@SCORE.Stanford.EDU, reddy@FAS.RI.CMU.EDU
A comment on my previous message has led me to qualify it.
If there were no pre-allocation of money to the Special Initiative, my
objections would be much less. However, the convening of a "panel of
experts" for this one program strongly suggests that at least implicit
commitments have been made to spend money even if the science and
engineering is weaker than in other proposals. So my request for
information still stands.
I should also make explicit that I have no specific objection to
multi-disciplinary or multi-investigator proposals provided they
compete directly with other proposals.
∂29-Aug-88 1025 TAJNAI@Score.Stanford.EDU Computer Aided Instruction
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Aug 88 10:25:05 PDT
Date: Mon 29 Aug 88 10:23:15-PDT
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Computer Aided Instruction
To: csd@Score.Stanford.EDU, faculty@Score.Stanford.EDU
cc: hiller@Score.Stanford.EDU
Message-ID: <12426339805.23.TAJNAI@Score.Stanford.EDU>
Is work being done on campus in the area of computer aided instruction?
Dr. Suppes?
Carolyn
-------
∂29-Aug-88 1640 SARAIYA@SUMEX-AIM.Stanford.EDU
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Aug 88 16:40:40 PDT
Return-Path: <weening@Gang-of-Four.Stanford.EDU>
Received: from Gang-of-Four.Stanford.EDU by SUMEX-AIM.Stanford.EDU with TCP; Mon, 29 Aug 88 16:20:40 PDT
Received: by Gang-of-Four.Stanford.EDU (5.59/25-eef) id AA05268; Mon, 29 Aug 88 16:20:52 PDT
Date: Mon, 29 Aug 88 16:20:52 PDT
From: Joe Weening <weening@Gang-of-Four.Stanford.EDU>
Message-Id: <8808292320.AA05268@Gang-of-Four.Stanford.EDU>
To: qlisp@Gang-of-Four.Stanford.EDU
ReSent-Date: Mon, 29 Aug 88 16:34:38 PDT
ReSent-From: Nakul P. Saraiya <SARAIYA@SUMEX-AIM.Stanford.EDU>
ReSent-To: aap@SUMEX-AIM.Stanford.EDU
ReSent-Message-ID: <12426407413.61.SARAIYA@SUMEX-AIM.Stanford.EDU>
From: fpst@hubcap.UUCP (Steve Stevenson)
Newsgroups: comp.parallel
Subject: PARALLEL ARCHITECTURES AND LANGUAGES EUROPE
Message-ID: <2888@hubcap.UUCP>
Date: 29 Aug 88 12:26:42 GMT
Organization: Clemson University, Clemson, SC
Lines: 103
SECOND CALL FOR PAPERS PARLE89
=========================================================================
PARALLEL ARCHITECTURES AND LANGUAGES EUROPE
12-16 JUNE 1989, EINDHOVEN, THE NETHERLANDS
DEADLINE FOR SUBMITTING YOUR FULL DRAFT: 21 OCTOBER 1988
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
PARLE 89, the second conference on Parallel Architectures and Languages
Europe, is intended to serve as a meeting place for researchers in the
fields of theory, design and applications of parallel computer systems.
The general scope of the conference is defined below. The initiative for
the conference was taken by project 415 of the European Strategic
Programme for Research and Development in Information Technology (ESPRIT)
of the Commission of the European Communities.
SCOPE OF THE CONFERENCE
Papers are solicited on any aspect of Parallel Architectures and
Languages. Topics of interest include, but are not limited to:
#CONCEPTS AND PARADIGMS FOR PARALLEL SYSTEMS.
Concurrent, object-oriented, logic, and functional programming.
Process theory and Petri nets.
Formal methods for design, specification, and verification.
#LANGUAGES AND MODELS FOR PARALLEL PROCESSING.
Parallel languages and programming methodologies.
Synchronization and communication.
Semantics and models for parallelism.
Programming environments.
#DESIGN AND IMPLEMENTATION OF PARALLEL ARCHITECTURES.
MIMD, SIMD, dataflow, inference and reduction computers.
VLSI, ULSI, and RISC architectures for parallel machines
Interconnection networks.
Memory management, fault tolerance, real time aspects.
Experience with working systems.
#SPECIAL PURPOSE PARALLEL SYSTEMS.
Dedicated processors for AI.
Systolic arrays, neural networks.
Distributed databases and parallel database machines.
#EVALUATION OF PARALLEL SYSTEMS.
Performance.
Simulation.
Debugging and monitoring tools.
#APPLICATIONS OF PARALLEL PROCESSING.
Applications in AI and symbolic computation.
SUBMISSION OF PAPERS
Authors are invited to submit five copies, in english, of a draft full paper
not exceeding 6000 words, before October 21, 1988, to one of the program
committee chairmen:
Prof. Dr. M. Rem Dr. J.C. Syre
Eindhoven University of European Computer Industry
Technology Research Centre
P.O.Box 513 Arabellastrasse 17
5600 MB Eindhoven D-8000 Munchen 81
The Netherlands West Germany
mcvax!eutrc3!wsinrem jclaude@ecrcvax.uucp
An additional page will give the title of the paper, the authors'names and
addresses (including e-mail, phone and fax to accelerate communication), the
area topic taken from above, and a summary of 150-200 words.
Papers not fulfilling the above conditions will not be considered for
reviewing. Papers arrived later than Oct 21st will not be considered unless
their authors notify the program chairman of a possible post delay.
Authors will be notified of acceptance or rejection by February 1, 1989.
For the inclusion in the conference proceedings to be published in the
Springer Lecture Notes in Computer Science Series, the final camera-ready
copy must be received before March 20, 1989.
ACT NOW ! SEND YOUR CONTRIBUTION TO THE BIG EUROPEAN CONFERENCE ON
PARALLEL PROCESSING
=========================================================================
Jean-Claude Syre off: +49 (0)89 92 699 127
Computer Architecture Group sec: +49 (0)89 92 699 153
European Computer Industry Research Centre rec: +49 (0)89 92 699 1
Arabellastr. 17 fax: +49 (0)89 92 699 170
D-8000 Munich 81 email: jclaude@ecrcvax
West Germany "in AI, one thing is sure: nothing is certain"
======== nothing to claim, hence nothing to disclaim, dig it?============
--
Steve Stevenson fpst@hubcap.clemson.edu
(aka D. E. Stevenson), fpst@prism.clemson.csnet
Department of Computer Science, comp.parallel
Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell
∂30-Aug-88 1212 ingrid@russell.stanford.edu visiting scholar cards
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Aug 88 12:12:49 PDT
Received: from russell.stanford.edu by csli.Stanford.EDU (4.0/4.7); Tue, 30 Aug 88 12:08:19 PDT
Received: from localhost by russell.stanford.edu (3.2/4.7); Tue, 30 Aug 88 12:12:14 PDT
To: research@russell.stanford.edu
Subject: visiting scholar cards
Date: Tue, 30 Aug 88 12:12:12 PDT
From: ingrid@russell.stanford.edu
For those of you who are not university employees: Your new visiting
scholar cards are on their way to you. Stanford parking permits go on
sale at the Parking Office (711 Serra Street, tel. 723-9633) on 1
September.
Ingrid
∂30-Aug-88 1630 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu libraries
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Aug 88 16:30:30 PDT
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 30 Aug 88 16:27:25-PDT
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA15895; Tue, 30 Aug 88 16:23:22 PDT
Date: Tue, 30 Aug 88 16:23:22 PDT
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8808302323.AA15895@Tenaya.stanford.edu>
To: faculty@score
Subject: libraries
Rebecca Lasher, our CS/Math Librarian, has asked for someone from CS
to join the newly formed Near West Campus Libary Committee (purpose of
committee is probably to make recommendations about the libraries to
be built in the NWC). Any volunteers? -Nils
∂31-Aug-88 1108 HEMENWAY@Score.Stanford.EDU Help Needed!
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 31 Aug 88 11:08:27 PDT
Date: Wed 31 Aug 88 11:04:37-PDT
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Help Needed!
To: ac@Score.Stanford.EDU
Message-ID: <12426871623.23.HEMENWAY@Score.Stanford.EDU>
We have run into a last-minute emergency with Michael Lowry's Orals
Examination Committee and need to add an Academic Council member to
it. The Orals are scheduled for this Friday, September 2, at 2:15
(yes, the same time as Lia Adams', an unavoidable conflict). I would
deeply appreciate hearing from any Academic Council member who would
be willing to serve on the Orals Committee. The other members are
Profs. Binford (advisor) and Genesereth, Joseph Goguen and Douglas
Smith.
Many thanks for your help.
Sharon
P.S. A caveat...this snafu was not Mike's fault but was caused by
different mistaken assumptions on both his and my part. Unfortunately,
this snafu will cause the cancellation of his Orals unless we can
find a 3rd AC member. Your help is asked for...
-------
∂01-Sep-88 0957 HAILPERIN@SUMEX-AIM.Stanford.EDU PPeALS proceedings
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Sep 88 09:57:53 PDT
Date: Thu, 1 Sep 88 09:49:02 PDT
From: Max Hailperin <HAILPERIN@SUMEX-AIM.Stanford.EDU>
Subject: PPeALS proceedings
To: aap@SUMEX-AIM.Stanford.EDU
Message-ID: <12427120010.50.HAILPERIN@SUMEX-AIM.Stanford.EDU>
I've the proceedings of PPEALS for a day if any of you wants to look at it.
-------
∂01-Sep-88 1349 TAJNAI@Score.Stanford.EDU FORUM: The Beginning of a New Fiscal Year
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Sep 88 13:49:33 PDT
Date: Thu 1 Sep 88 13:45:59-PDT
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: FORUM: The Beginning of a New Fiscal Year
To: csd@Score.Stanford.EDU, faculty@Score.Stanford.EDU,
csl-everyone@Sierra.Stanford.EDU
Message-ID: <12427163143.26.TAJNAI@Score.Stanford.EDU>
Today is September 1, and we are embarking on a new fiscal year.
1987/88 was a banner year for the Forum -- all goals and expectations
were exceeded!
Membership is 78 companies. We brought in $1,363,252 to CSD/CSL. For
those of you unfamiliar with the way the Forum operates, the following
might be interesting.
1. We run the Forum program on approximately 20% of the income.
However, we have used much less than 20% in 1987/88. Final
expenditure statements are not in, but it will probably be
closer to 16%. This includes salaries, computer time, equipment,
telephone, supplies, annual meeting expenses, benefits to
Forum company members (research reports, resume books, videotapes,
etc.)
2. Usually about 30% goes to faculty, but this year it is closer to 34%.
3. 25% to CSL
4. 25% to CSD.
To CSD/CSL -- faculty, students, and staff: It takes all of us to
make the Computer Forum successful. The Forum is #1 among departmental
affiliates program, and the reason we are #1 is because we share a
commitment to the Forum. We in CSD and CSL are the Forum. Let's
work together and go for the GOLD in 88/89 -- how about 1 1/2 M!!
Carolyn Tajnai
-------
∂01-Sep-88 1954 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu 2 Dim bin packing
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Sep 88 19:54:34 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA29284; Thu, 1 Sep 88 19:53:14 PDT
Message-Id: <8809020253.AA29284@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 1 Sep 88 19:54:28 PDT
Received: by BYUADMIN (Mailer X1.25) id 8663; Thu, 01 Sep 88 20:52:01 MDT
Date: Thu, 1 Sep 88 21:49:43 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
David Abramson <rcoda%koel.co.rmit.oz.au@RELAY.CS.NET>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: David Abramson <rcoda%koel.co.rmit.oz.au@RELAY.CS.NET>
Subject: 2 Dim bin packing
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Can anyone please provide me with a small, recent list of references
on the 2 dimensional bin packing problem and solutions?
Thanks
Dr David Abramson
ACSnet: rcoda@koel.co UUCP: ...!uunet!munnari!koel.co.rmit.oz!rcoda
CSNET: rcoda@koel.co.rmit.oz ARPA: rcoda%koel.co.rmit.oz@uunet.uu.net
BITNET: rcoda%koel.co.rmit.oz@CSNET-RELAY PHONE: + 61 3 660 2095
Commonwealth Scientific and Research Organisation,
Division of Information Technology,
c/o Department of Communication & Electronic Engineering,
Royal Melbourne Institute of Technology,
P.O. Box 2476V,
Latrobe St, Melbourne, 3000, Australia
∂04-Sep-88 1342 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Sep 88 13:42:31 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 SEP 88 13:39:41 PDT
Date: 4 Sep 88 13:39 PDT
From: Masinter.pa@Xerox.COM
to: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE (version 12)
line-fold: NO
Message-ID: <880904-133941-8818@Xerox>
This is the final version of the FUNCTION-TYPE issue, as passed at the June 88 X3J13 meeting; that is, it incorporates the amendments that were adopted before the issue was adopted.
I hope to be getting issues out to the X3J13 list as the cleanup committee comes to some final agreement on them, over the next two weeks.
!
Issue: FUNCTION-TYPE
References: functions (p32), types (p33), FUNCTIONP (p76),
SYMBOL-FUNCTION (p90), APPLY (p107), COERCE (pp51-52)
Category: CHANGE
Edit History: 26-Feb-87, Version 1 by Gabriel
15-Mar-87, Version 2 by Cleanup Committee
10-May-87, Version 3 by Fahlman
29-May-87, Version 4 by Masinter (incorporate comments)
15-Jun-87, Version 5 by Fahlman (include two options)
23-Oct-87, Version 6 by Masinter (only STRICT-REDEFINITION)
09-Nov-87, Version 7 by Masinter (minor cleanup)
14-Nov-87, Version 8 by Pitman (major restructuring)
13-Feb-88, Version 9 by Masinter, (add back 2nd option)
19-May-88, Version 10 by Masinter, (modify as per X3J13)
24-May-88, Version 11 by van Roggen
(don't coerce lists, relax SYMBOL-FUNCTION reqs)
4-Sep-88, Version 12 by Masinter
(incorporate amendments adopted at June 88 X3J13)
Problem Description:
The definition of the term ``function'' in CLtL includes all symbols and
many lists in addition to `true' functions.
Also, page 47 of CLtL states that the FUNCTION type specifier can only
be used for declaration and not for discrimination. Some of the original
Common Lisp designers maintain that this restriction on the use of the
FUNCTION specifier was meant to apply only to long-form FUNCTION
specifiers, but since this intent was not explicitly stated, the status
of FUNCTION as a type is blurred.
A consequence of the p47 confusion is that (FUNCTIONP x) cannot portably
be relied upon to be equivalent to (TYPEP x 'FUNCTION).
Proposal FUNCTION-TYPE:X3J13-MARCH-88
This proposal is basically the STRICT-REDEFINITION proposal of version 9
of this issue, correcting a few typos, changing section 2E as
agreed upon at X3J13 March 1988, allowing symbols but not lists to
be FUNCALLed or APPLYed, and relaxing some SYMBOL-FUNCTION/FBOUNDP
requirements.
1. Redefine the type FUNCTION so that it can be used for discrimination
as well as declaration.
1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION
are pairwise disjoint. In particular, a list may not be used
to implement any FUNCTION subtype.
1b. Define that the type COMPILED-FUNCTION is a subtype of FUNCTION.
Implementations are free to define other subtypes of FUNCTION.
2. Define that a ``function'' as used throughout the CLtL is restricted
to be exactly those objects of type FUNCTION.
2a. This type no longer includes objects of type SYMBOL or lists
whose CAR is LAMBDA.
2b. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). This is an incompatible
change.
2c. Clarify that the list form of the FUNCTION type specifier may
still only be used for declaration.
2d. Clarify that the symbol form of the FUNCTION type specifier may
be used for type discrimination.
2e. FUNCALL and APPLY and all Common Lisp functions that
take function arguments to also take a symbol, which will
be coerced to a function as if by SYMBOL-FUNCTION.
2f. This is an incompatible change in that it is an error to pass
anything other than a function or symbol as the functional
argument.
3. Clarify that the result of a FUNCTION special form must be a function.
3a. This implies that some (FUNCTION name) may be implicitly interpreted
as (THE FUNCTION (FUNCTION name)).
4. Clarify that it is an error to use the special form FUNCTION on a
symbol that does not denote a function in the lexical environment in
which the special form appears. Specifically, it is an error to use the
FUNCTION special form on a symbol that denotes a macro or special form.
4a. Some implementations may choose not to signal this error for
performance reasons, but implementations are forbidden from
defining the failure to signal an error as a `useful' behavior.
5. Clarify that FBOUNDP must return true for a symbol naming a macro or
a special form, and that it is permissible to call SYMBOL-FUNCTION
on any symbol for which FBOUNDP returns true.
5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
but the symbol denotes a macro or special form is not well-defined,
but SYMBOL-FUNCTION will not signal an error.
5b. SETF of SYMBOL-FUNCTION requires a FUNCTION as the new value.
It is an error to set the SYMBOL-FUNCTION of a symbol to a
symbol or a list or the value returned by SYMBOL-FUNCTION on
the name of a macro or a special form.
5c. The motivation for this distinction between FUNCTION and
SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
use within programs while SYMBOL-FUNCTION is a data structure
accessor used primarily for meta-level applications and not
recommended for general use. It is provided primarily to
complete the set of accessors on symbols.
6. COERCE is extended to allow objects to be coerced to type FUNCTION.
6a. (COERCE symbol 'FUNCTION) extracts the SYMBOL-FUNCTION of the
given symbol, signalling an error if the symbol is not FBOUNDP or
if the symbol names a macro or a special-form.
6b. (COERCE x 'FUNCTION), where the value of x is a list that
begins with LAMBDA, will return a FUNCTION similar to
(EVAL '(FUNCTION ,x)).
7. Clarify that the value of *MACROEXPAND-HOOK* is first coerced to a
function before being called as the expansion interface hook by
MACROEXPAND-1.
Rationale:
The fuzzy definition of ``function'' has descended from older dialects of
Lisp, such as Maclisp. Many places in existing code make assumptions about
the current meaning, making any change painful.
It is very important both for documentation clarity and for program type
discrimination (such as CLOS) to have a clear term which denotes a
``true function.''
This proposal is a compromise between a CONSERVATIVE proposal (which left
FUNCTION alone and introduced a new type), and a STRICT-REDEFINITION proposal,
which incompatibly changed not only the FUNCTION type and SYMBOL-FUNCTION,
but also the behavior of FUNCALL, APPLY and functions with functional
arguments.
For compatibility reasons symbols are still acceptable to FUNCALL et al.,
but for aesthetic reasons lambda-expressions (lists whose CAR is LAMBDA
and whose CADR is a list) are no longer acceptable.
Current Practice:
In some implementations, (TYPEP x 'FUNCTION) signals an error.
In some implementations, (TYPEP x 'FUNCTION) is true for values
returned by FUNCTION, symbols that are FBOUNDP, and lambda expressions.
In some implementations, (TYPEP x 'FUNCTION) is true only for values
returned by FUNCTION.
Implementations vary on what my go into the function cell, depending on
how much error checking they want to have to do at function call time, and
depending on whether they store other kinds of information (such as special
form information) in the function cell.
Few current Common Lisp implementations have exactly the
semantics described in this proposal.
Cost to Implementors:
Bringing type predicates (FUNCTIONP, etc.) and higher order functions
(APPLY, etc.) into compliance should require little effort in most
implementations.
Compiled functions are true functions in almost all current
implementations, but in many implementations, interpreted functions and
closures stored in the function cell of a symbol are represented as lists.
Under this proposal, this representation would have to be different
(implemented either as structures or as some special internal data type).
The behavior of COMPILE, STEP, TRACE, and possibly ED would have to be
modified to deal with functions that are not lists (but from which the
list form can be reconstructed if necessary).
Cost to Users:
The changes to FUNCTIONP and the FUNCTION type declaration are relatively easy
to deal with.
Because CLtL's language was somewhat fuzzy about what might go into the
function cell of a symbol, some code that explicitly deposited symbols
or lists in a symbol's function cell, or expected lists back, will
have to change. Such code was already not portable, however, since some
implementations signal an error when this is done.
The original STRICT-REDEFINITION proposal required users to deal with
the use of symbols and lambda-expressions as functional arguments. However
this proposal is compatible with current CLtL definition in the use of
symbols, which would be the hardest change to make. There are probably
relatively few uses of lambda-expressions as ``functions'', which can
be dealt with by (EVAL `(FUNCTION ,lambda-expresssion)).
Benefits:
The term ``function'' would be given a useful and precise meaning.
The FUNCTION datatype would be useful for type discrimination in CLOS.
The type hierarchy would be simplified.
This proposal brings Common Lisp slightly closer to Scheme and the
work of the EuLisp committee. Scheme, for example, also has the concept
of a ``procedure'' which is compatible with the FUNCTION type.
Aesthetics:
This proposal improves the aesthetics of the language.
Lambda-expressions do not obey the normal, apparent scoping rules because
free variables cannot refer to lexical bindings. This is because
coercing a list to a function would mean (EVAL `(FUNCTION ,list)).
The following code does -not- count the number of nodes in a graph:
(LET ((COUNTER 0))
(TRAVERSE-THING '(LAMBDA (NODE) (INCF COUNTER))
(THING-ROOT)))
since it is not the same as
(LET ((COUNTER 0))
(TRAVERSE-THING #'(LAMBDA (NODE) (INCF COUNTER))
(THING-ROOT)))
which does pass around a closure incrementing the LET variable.
(These examples assume COUNTER wasn't PROCLAIMed SPECIAL.)
Making the coercion of lambda-expressions to functions explicit with
the use of EVAL will encourage less confusing code and also highlight
that use of EVAL.
Discussion:
This issue has been discussed at great length; this section attempts
only to summarize the important points.
There is general agreement that the definition of the FUNCTION data type
must be clarified or revised. The cleanup of the type hierarchy is important
to the CLOS group.
The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". We believe this is a subject for a separate
proposal, as the behavior of COMPILE needs additional clarification.
Many different alternatives have been discussed both in the cleanup committee
and X3J13. Two proposals were circulated at the March 1988 meeting of X3J13;
this version is the result of discussions at that meeting. It is a compromise
between the conflicting goals of backward compatibility, flexibility in the
language, and simple semantics.
This proposal does not address the issue of when coercion to functions occur.
For example, it is allowed to write
(MAPCAR 'FROB my-list)
It is not specified when the coercion of FROB to its SYMBOL-FUNCTION
occurs. For example,
(DEFUN FROB (X)
(WHEN (> X 0) (SETF (SYMBOL-FUNCTION 'FROB) #'(LAMBDA (X) NIL)))
T)
(MAPCAR 'FROB '(-1 -1 1 1))
may return different results if MAPCAR coerces its functional argument
once rather than for each element. This may require a separate
cleanup issue.
∂04-Sep-88 1352 X3J13-mailer Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED (version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Sep 88 13:52:29 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 SEP 88 13:51:24 PDT
Date: 4 Sep 88 13:51 PDT
From: Masinter.pa@Xerox.COM
To: X3J13@sail.stanford.edu
CC: Masinter.pa@Xerox.COM
Subject: Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED (version 2)
reply-to: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <880904-135124-8828@Xerox>
This is the final version as amended & subsequently passed.
>Guy Steele moved, and Dan Pierson seconded, to change the
>wording of the proposal as follows:
> "explicitly forbid" to be replaced by "it is an error for"
>The amendment passed unanimously.
>The amended proposal passed unanimously.
!
Issue: DATA-TYPES-HIERARCHY-UNDERSPECIFIED
References: CLtL 33-35 (data types)
CLtL 312 (DEFSTRUCT :INCLUDE option)
Category: CHANGE
Edit history: 24-Mar-88, version 1 by Steele
4-Sep-88, version 2 by X3J13 June 88
Problem description:
The types HASH-TABLE, READTABLE, PACKAGE, PATHNAME, STREAM, and
RANDOM-STATE currently are not required to be disjoint from CONS, SYMBOL,
ARRAY, NUMBER, or CHARACTER. The same is true of DEFSTRUCT types. With
the arrival of CLOS, lack of disjointness will be inconvenient because one
cannot reliably use generic function dispatch on these types.
Proposal (DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT):
Remove the third and antepenultimate bulleted items from section 2.15 is
CLtL and replace with the following:
* The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, HASH-TABLE, READTABLE,
PACKAGE, PATHNAME, STREAM, RANDOM-STATE, and any single other type created
by DEFSTRUCT [or DEFCLASS] are pairwise disjoint.
Also, in the discussion of the DEFSTRUCT :INCLUDE option, it is an error for
the type given to the :INCLUDE option to be CONS, SYMBOL, ARRAY, NUMBER,
CHARACTER, HASH-TABLE, READTABLE, PACKAGE, PATHNAME, STREAM, or
RANDOM-STATE.
Rationale:
It would be useful to extend sequence functions to operate on streams
or hash tables, for example, through the CLOS generic function mechanism.
This is not possible under the current specification.
Current practice:
Some implementations in effect use DEFSTRUCT to define data structures
such as hash tables and random-states.
Cost to Implementors:
Small or nonexistent. The main reason this disjointness was not specified
in CLtL was the possibility that structures might not be easily
distinguishable: a stupid concern over a slight efficiency. This
implementation freedom apparently has not been exploited in practice.
Cost to Users:
None.
Cost of non-adoption:
CLOS will be less useful.
Benefits:
CLOS will be more useful.
Esthetics:
This makes the type system simpler and easier to understand.
Discussion:
This suggestion originated in the CLOS committee.
----- End Forwarded Messages -----
∂05-Sep-88 1439 TAJNAI@Score.Stanford.EDU faculty and student honors
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Sep 88 14:39:10 PDT
Date: Mon 5 Sep 88 14:35:39-PDT
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: faculty and student honors
To: faculty@Score.Stanford.EDU, sec@Score.Stanford.EDU
Message-ID: <12428220763.9.TAJNAI@Score.Stanford.EDU>
During the year I have been collecting information about honors,
but just to make sure, please send me information to include in
Nils' Newletter to CSD alumni and friends.
What about Guggenheim Awards
-------
∂06-Sep-88 1129 barwise@russell.stanford.edu reading list
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Sep 88 11:29:30 PDT
Received: from russell.stanford.edu by csli.Stanford.EDU (4.0/4.7); Tue, 6 Sep 88 11:28:37 PDT
Received: from localhost by russell.stanford.edu (3.2/4.7); Tue, 6 Sep 88 11:32:26 PDT
To: ssp-faculty@russell.stanford.edu
Subject: reading list
Date: Tue, 06 Sep 88 11:32:25 PDT
From: Jon Barwise <barwise@russell.stanford.edu>
We are preparing a little booklet about the SSP major and need to have
a short reading list. Here is what we have come up with. We would
like suggestions for additions and deletions. We can have at most 10
books, and they need to be for Stanford Frosh who have not taken many
(if any) of our courses. Help please.
PLease reply to Helen@russell since I will be away.
Cognitive Science: An Introduction, by Stillings, Feinstein, et. al.,
MIT PRess, 1987
AI: The Very Idea
-Haugeland
Computers and Cognition
-Winograd and Flores
The Mind's New Science
-Gardener
Mind Design
-ed. Haugeland
Parallel Distributed Processing
-Rummelhart and McClelland
Computation and Cognition
-Zenon Pylyshyn
Logical Foundations of AI
-Nilsson and Genesereth
Something by Chomsky (what?)
∂06-Sep-88 1324 nilsson@Tenaya.stanford.edu reading list
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Sep 88 13:24:32 PDT
Received: from russell.stanford.edu by csli.Stanford.EDU (4.0/4.7); Tue, 6 Sep 88 13:23:36 PDT
Received: from Tenaya.stanford.edu by russell.stanford.edu (3.2/4.7); Tue, 6 Sep 88 13:27:25 PDT
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA20920; Tue, 6 Sep 88 13:18:21 PDT
Date: Tue, 6 Sep 88 13:18:21 PDT
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8809062018.AA20920@Tenaya.stanford.edu>
To: barwise@russell.stanford.edu
Cc: ssp-faculty@russell.stanford.edu
In-Reply-To: Jon Barwise's message of Tue, 06 Sep 88 11:32:25 PDT <8809061835.AA20836@Tenaya.stanford.edu>
Subject: reading list
The "Genesereth and Nilsson" book is difficult enough for its
authors, let alone freshman. I suggest it be purged from the list.
-Nils
∂06-Sep-88 1347 helen@russell.stanford.edu SSP
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Sep 88 13:47:20 PDT
Received: from russell.stanford.edu by csli.Stanford.EDU (4.0/4.7); Tue, 6 Sep 88 13:46:33 PDT
Received: by russell.stanford.edu (3.2/4.7); Tue, 6 Sep 88 13:50:23 PDT
Date: Tue 6 Sep 88 13:50:22-PDT
From: Helen Nissenbaum <HELEN@Russell.Stanford.EDU>
Subject: SSP
To: ssp-faculty@russell.stanford.edu
Cc: kuder@russell.stanford.edu
Message-Id: <589582222.0.HELEN@Russell.Stanford.EDU>
Mail-System-Version: <SUN-MM(244)+TOPSLIB(128)@Russell.Stanford.EDU>
Greetings All!
I'm back from my year-long leave and looking forward to working once again
in the program. We will be keeping regular office hours: Mornings only
Monday and Tuesday, and until 4:30 Wednesday - Friday.
From now until the start of the school year our main project is putting
together a booklet about SSP. We're updating and compiling information about
the program, the faculty, and the courses. From time to time we'll need help.
Most immediately: we're creating a list of the program's faculty and need
a few lines from each of you describing your research interests, and examples
of books or articles you've written, or any project you've worked on, or are
currently working on that might be of interest to majors (or prospective majors)
Under research interests, a few key phrases will be fine, and under projects
list two or three. Here is what Jon wrote to give you an idea of scope.
{\bf Jon Barwise}, Director, Department of Philosophy. Research
interests: logic, semantics of natural language, information theory.
Selected publications: {\it The Liar}, with John Etchemendy, and {\it
Situations and Attitudes}, with John Perry. Editor of the {\it
Handbook of Mathematical Logic.}
It would be really nice if you could get this to me by the end of the week.
Thanks
Helen Nissenbaum
(back as your Program Coordinator)
-------
∂06-Sep-88 1441 LOGMTC-mailer Trakhtenbrot
Received: from jeeves.stanford.edu by SAIL.Stanford.EDU with TCP; 6 Sep 88 14:41:46 PDT
Received: by jeeves.stanford.edu (4.0/SMI-DDN)
id AA16696; Tue, 6 Sep 88 14:40:42 PDT
Date: Tue, 6 Sep 88 14:40:42 PDT
From: jcm@jeeves.stanford.edu (John Mitchell)
Message-Id: <8809062140.AA16696@jeeves.stanford.edu>
To: logmtc@sail
Subject: Trakhtenbrot
Seminar Wednesday, Sept. 14, 11 AM, Room 252 MJH
Nets of Processes
B.A.Trakhtenbrot
Tel-Aviv University
Nets of Processes provide a framework which covers in an
uniform way different known models of concurrent systems.
In this framework we analyze the controversy between
Interleaving Concurrency and Partial Order (also called "True")
Concurrengy. In particular, we investigate situations when
for a given system N there is a strong intuition and a general
consensus that N behaves globally as an automaton, but the
inherent causal aspects of this interleaving behavior have
still to be made explicit. Applications to Petri Nets and to
Data Flow Networks are considered.
(Joint work with Alex Rabinovich)
------
Please let me know if you would like to talk
to Trakhtenbrot later Wednesday afternoon. -jcm
∂06-Sep-88 2007 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu MAMLS conference at Rutgers on September 17
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Sep 88 20:07:10 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA03499; Tue, 6 Sep 88 20:05:47 PDT
Message-Id: <8809070305.AA03499@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 6 Sep 88 20:06:59 PDT
Received: by BYUADMIN (Mailer X1.25) id 6757; Tue, 06 Sep 88 21:02:10 MDT
Date: Tue, 6 Sep 88 21:54:16 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
cherlin%MATH.RUTGERS.EDU@Forsythe.Stanford.EDU
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: cherlin%MATH.RUTGERS.EDU@Forsythe.Stanford.EDU
Subject: MAMLS conference at Rutgers on September 17
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Sept. 17 MAMLS conference in Room 705 Hill Center, Busch Campus
Rutgers University, New Brunswick, NJ.
9:00- 9:30 Coffee
9:30-10:30 Shelah A Jonsson algebra on aleph-w+1
is easy
*10:40-11:40 Gurevich Deterministic vs.
Nondeterministic Linear Time
*11:50-12:50 Immerman On the number of variables
needed to describe graphs
Lunch Break
2:30- 3:30 Hrushovski Some pseudoplane constructions
3:40- 4:40 Macintyre Transfer principles for integral
closures
Dinner: We will need a count on the number interested in dining
at La Charcuterie in the Princeton Shopping Center.
The main course runs $15-$20 and a full meal can easily
run $35.
Party at the Cherlins' at 9P.M. 85 Clearview Ave., Princeton,
Near the Harrison St. Shopping Center.
Tel: 609 921-9205
There is some room for overnight guests at the Cherlins' and at
Simon Thomas' house (tel. (609) 771-8316).
Sheraton Hotel, Centennial off Rte. 18, West of Busch
Campus. Tel. (201) 469-5700. $55 Rutgers rate
Directions. Route 1 or Turnpike (exit 9) to New Brunswick,
Route 18 West across Raritan River to Metlar's Lane (straight
ahead after the bridge), up Metlar's Lane to Brett Road (2nd
left) and wind around to Hill Center Parking Lot.
Future meetings: Baruch College, NYC Dec. 3
Univ. Penn., Phila. Mar. 4
The Greater Boston Logic Meeting, in April.
∂07-Sep-88 0914 AAAI-OFFICE@SUMEX-AIM.Stanford.EDU News re: CCM
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Sep 88 09:14:31 PDT
Date: Wed, 7 Sep 88 09:05:50 PDT
From: AAAI <AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>
Subject: News re: CCM
To: officers: ;
cc: AAAI-OFFICE@SUMEX-AIM.Stanford.EDU
Telephone: (415) 328-3123
Postal-Address: 445 Burgess Drive, Menlo Park, CA 94025
Message-ID: <12428685008.32.AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>
Gentlemen:
Claudia is entering the El Camino Hospital in Mt. View for Thursday gall
bladder surgery. She should be recuperating back at home in 3-5 days, and
hopes to be returning to the office at the end of September.
Rick Skalsky
-------
∂07-Sep-88 1540 JMC@SAIL.Stanford.EDU Reading list
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Sep 88 15:40:04 PDT
Received: from russell.stanford.edu by csli.Stanford.EDU (4.0/4.7); Wed, 7 Sep 88 15:39:04 PDT
Received: from SAIL.Stanford.EDU by russell.stanford.edu (3.2/4.7); Wed, 7 Sep 88 15:42:51 PDT
Message-Id: <1W#s$q@SAIL.Stanford.EDU>
Date: 07 Sep 88 1538 PDT
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: Reading list
To: helen@RUSSELL.Stanford.EDU, ssp-faculty@RUSSELL.Stanford.EDU
I would favor putting Daniel Dennett's "The Intentional Stance" on the
Symbolic Systems on the reading list. It could readily directly replace
Pylyshyn' book, for example. It is more appropriate for people interested
in symbolic systems and much more comprehensible. Also it's correct.
It could also replace Gardener.
∂07-Sep-88 1604 ARCEO@Warbucks.AI.SRI.COM seminar, d. smith, 9/14
Received: from Warbucks.AI.SRI.COM by SAIL.Stanford.EDU with TCP; 7 Sep 88 16:04:23 PDT
Date: Wed 7 Sep 88 15:24:58-PDT
From: ARCEO@Warbucks.AI.SRI.COM (Dori Arceo)
Subject: seminar, d. smith, 9/14
To: aic-associates@Warbucks.AI.SRI.COM, planlunch@Warbucks.AI.SRI.COM,
csl-distribution@Warbucks.AI.SRI.COM, bboard@Warbucks.AI.SRI.COM,
su-bboards@sail.stanford.edu
cc: smith@kestrel.arpa
Message-ID: <589674299.0.ARCEO@WARBUCKS.AI.SRI.COM>
Mail-System-Version: <VAX-MM(229)+TOPSLIB(126)@WARBUCKS.AI.SRI.COM>
Title: KIDS - A Knowledge-Based Software Development System
Speaker: Douglas R. Smith
Kestrel Institue
Where: AI Center Conference Room
EJ228
Building E
SRI International
333 Ravenswood Ave., Menlo Park
When: Wednesday, 14 September
4:15 p.m.
(Visitors from outside come early to be escorted)
Coffee: 3:45 p.m., Waldinger Office
Abstract: KIDS (Kestrel Interactive Development System) is an
experimental knowledge-based software development system that
integrates a number of sources of programming knowledge. It is used
to interactively develop formal specifications into correct and
efficient programs. Tools for performing algorithm design, a
generalized form of deductive inference, program simplification,
finite differencing optimizations, partial evaluation, and (soon) data
structure selection are available to the program developer. We
describe these tools and discuss the derivation of several programs.
All of the KIDS tools are automatic except the algorithm design
tactics which require some interaction at present. Dozens of
derivations have been performed using the KIDS environment and we
believe that it is close to the point where it can be used for some
routine programming.
-------
∂08-Sep-88 1318 LOGMTC-mailer seminar, d. smith, 9/14
Received: from Warbucks.AI.SRI.COM by SAIL.Stanford.EDU with TCP; 8 Sep 88 13:18:17 PDT
Return-Path: <ARCEO@Warbucks.AI.SRI.COM>
Date: Wed 7 Sep 88 15:24:58-PDT
From: ARCEO@Warbucks.AI.SRI.COM (Dori Arceo)
Subject: seminar, d. smith, 9/14
To: aic-associates@Warbucks.AI.SRI.COM, planlunch@Warbucks.AI.SRI.COM,
csl-distribution@Warbucks.AI.SRI.COM, bboard@Warbucks.AI.SRI.COM,
su-bboards@sail.stanford.edu
cc: smith@kestrel.arpa
Message-ID: <589674299.0.ARCEO@WARBUCKS.AI.SRI.COM>
Mail-System-Version: <VAX-MM(229)+TOPSLIB(126)@WARBUCKS.AI.SRI.COM>
ReSent-date: Thu 8 Sep 88 13:11:04-PDT
Resent-From: WALDINGER@Warbucks.AI.SRI.COM (Richard Waldinger)
Resent-To: csl-seminar@Warbucks.AI.SRI.COM, logmtc@sail.stanford.edu
Title: KIDS - A Knowledge-Based Software Development System
Speaker: Douglas R. Smith
Kestrel Institue
Where: AI Center Conference Room
EJ228
Building E
SRI International
333 Ravenswood Ave., Menlo Park
When: Wednesday, 14 September
4:15 p.m.
(Visitors from outside come early to be escorted)
Coffee: 3:45 p.m., Waldinger Office
Abstract: KIDS (Kestrel Interactive Development System) is an
experimental knowledge-based software development system that
integrates a number of sources of programming knowledge. It is used
to interactively develop formal specifications into correct and
efficient programs. Tools for performing algorithm design, a
generalized form of deductive inference, program simplification,
finite differencing optimizations, partial evaluation, and (soon) data
structure selection are available to the program developer. We
describe these tools and discuss the derivation of several programs.
All of the KIDS tools are automatic except the algorithm design
tactics which require some interaction at present. Dozens of
derivations have been performed using the KIDS environment and we
believe that it is close to the point where it can be used for some
routine programming.
-------
∂08-Sep-88 1751 X3J13-mailer Fairfax X3 registration form
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 8 Sep 88 17:51:20 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00481g; Thu, 8 Sep 88 16:50:15 PST
Received: by challenger id AA05802g; Thu, 8 Sep 88 17:48:06 PDT
Date: Thu, 8 Sep 88 17:48:06 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809090048.AA05802@challenger>
To: x3j13@sail.stanford.edu
Subject: Fairfax X3 registration form
I've had a few people ask about the dates of the next meeting... The dates in
the last message were correct. It was decided to have only 1 day of
subcommittee meetings before the committee meeting in October. I have
included the last message pertaining the the Fairfax meeting and a
registration form. See you there! ---jan---
The next meeting of X3J13 will be held October 10-13, 1988, in Fairfax,
Virginia, at the Contel Technology Center at 12015 Lee Jackson Highway (US
Route 50). Monday (October 10) will be used for subcommittee meetings and
Tuesday and Wednesday (October 11 and 12) will be used for the general
meeting. If necessary, Thursday can also be used for subcommittee meetings.
The Contel Technology Center is located in the same building with Contel
Federal Systems across the parking lot from Fair Oaks Shopping Center. On the
other side of the shopping Center is the Holiday Inn Fair Oaks (11787 Lee
Jackson Highway, 703-352-2525) where some rooms are being held for our group.
These facilities are located at the intersection of US Route 50 and Interstate
66. This is outside the beltway two exits further west along I-66 from where
the Metro Orange line ends. Coming from National Airport, one would go by the
Pentagon along 110 through Rosslyn to go west on I-66. From Dulles airport,
take the first exit south onto Route 28 and then east on Route 50. The cab
fare from Dulles should be about $20 and from National about $30. There is
also bus service to Fair Oaks Shopping Center.
To register contact the hotel directly (and mention Contel and this group) and
Jan Zubkoff at Lucid. The meeting fee will be $50 (make checks payable to
Lucid). For special local questions, contact Bob Mathis. We need an
indication, as soon as possible, about attendance and subcommittee meeting
needs.
The agenda of this meeting should be quite full. We expect final (or almost
final) reports from ALL subcommittees. The CLOS committee is working toward
presenting chapter 3. The clean-up committee will have a number of issues to
review. The editorial committee has the beginnings of a draft. The compiler,
character, and iteration committees should also have reports. Will there be
any others? From the subcommittee leaders, I need any documents they want
distributed, their subcommittee meeting plans, their expectations about full
X3J13 actions, and their anticipated time on the agenda.
!
X3J13 October Meeting Registration Form
Please include a check for $50.00 payable to `LUCID' mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
jlz@lucid.com
Name: _____________________________________________________________
Institution: ______________________________________________________
Net-Address: ______________________________________________________
Phone: ____________________________________________________________
Attend X3J13 _________
Lunch 10/11: _________ yes _______ no
Lunch 10/12: _________ yes _______ no
∂09-Sep-88 0904 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Papers -- Mathematical Foundations of Programming
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Sep 88 09:04:05 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA24526; Fri, 9 Sep 88 09:02:35 PDT
Message-Id: <8809091602.AA24526@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 9 Sep 88 09:03:43 PDT
Received: by BYUADMIN (Mailer X1.25) id 4590; Fri, 09 Sep 88 10:00:35 MDT
Date: Fri, 9 Sep 88 10:41:42 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Dave Schmidt <schmidt%KSUVAX1.CIS.KSU.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Dave Schmidt <schmidt%KSUVAX1.CIS.KSU.EDU@Forsythe.Stanford.EDU>
Subject: Call for Papers -- Mathematical Foundations of Programming
Semantics
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
CALL FOR PAPERS
Fifth Workshop on the Mathematical Foundations
of Programming Semantics
Tulane University
New Orleans, Louisiana
March 29 - April 1, 1989
The workshop is the fifth in a series that is dedicated towards bringing
together computer scientists and mathematicians for discussion of
problems and directions in programming language semantics. Computer
scientists gain exposure to relevant mathematical ideas, and
mathematicians learn about mathematics-related applications and problems
in the programming semantics area.
The invited speakers are:
Samson Abramsky, Imperial College
Luca Cardelli, DEC Systems Research Center
Peter Freyd, University of Pennsylvania
Peter Johnstone, Cambridge University
John Reynolds, Carnegie-Mellon University
Papers are solicited on the following topics:
(1) Order-theoretic, topological and categorical approaches to semantics
(2) Formal and descriptive aspects of semantics notations
(3) The role of semantics in programming language design and analysis
(4) Application of semantics and related topics (e.g., polymorphism)
to the design and implementation of compilers and interpreters.
This list is not exhaustive, and papers in related areas that fit
with the intentions of the workshop are welcome.
An author may submit a paper by mailing 4 copies of a preliminary version
to either of the program committee chairmen:
David Schmidt Austin Melton
Computing and Info. Sciences Dept. Datalogisk Institut
Kansas State University Copenhagen University
Manhattan, KS 66506 Universitetsparken 1
913-532-6350 DK-2100 Copenhagen 0
Internet:schmidt@cis.ksu.edu DENMARK
Bitnet:schmidt@ksuvax1 Internet:austin@diku.dk
The preliminary version is limited to a length of 12 double spaced, typed
pages. The deadline for submission of the preliminary version is
November 15, 1988. Authors will be notified of acceptance or rejection by
February 10, 1989. In keeping with the spirit of the workshop, the final
version of an accepted paper will not be required for the workshop's
proceedings until May 10, 1989.
The proceedings of the first and third workshops in this series are
volumes 239 and 298 in Springer-Verlag's Lecture Notes in Computer Science,
and it is expected that the proceedings from this workshop will also appear
in LNCS.
The program committee consists of:
Boumediene Belkhouche, Tulane University
Stephen Brookes, Carnegie-Mellon University
Carl Gunter, University of Pennsylvania
Jimmie Lawson, Louisiana State University
Michael Main, University of Colorado
Michael Mislove, Tulane University
Frank Oles, IBM Yorktown
George Revesz, IBM Yorktown
Teodor Rus, University of Iowa
Robert Tennent, Queen's University
Eric Wagner, IBM Yorktown
Further information regarding the workshop may be obtained from the
general chairmen:
Michael Mislove Michael Main
Mathematics Department Computer Science Dept., CB430
Tulane University University of Colorado
New Orleans, LA 70118 Boulder, CO 80309
504-865-5727 303-492-7579
Bitnet: MT05AMF@TCSMUSA Internet: main@boulder.colorado.edu
The local arrangements chairman is:
Boumediene Belkhouche
Computer Science Department
Tulane University
New Orleans, LA 70118
504-865-5840
CSNET: bb@tulane.edu
A final program, listing the accepted papers, schedule, and
accommodation information, will be available from the chairmen
approximately February 15, 1989.
∂09-Sep-88 1549 helen@russell.stanford.edu descriptions
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Sep 88 15:49:26 PDT
Received: from russell.stanford.edu by csli.Stanford.EDU (4.0/4.7); Fri, 9 Sep 88 15:48:29 PDT
Received: by russell.stanford.edu (3.2/4.7); Fri, 9 Sep 88 15:52:17 PDT
Date: Fri 9 Sep 88 15:52:16-PDT
From: Helen Nissenbaum <HELEN@Russell.Stanford.EDU>
Subject: descriptions
To: ssp-faculty@russell.stanford.edu
Message-Id: <589848736.0.HELEN@Russell.Stanford.EDU>
Mail-System-Version: <SUN-MM(244)+TOPSLIB(128)@Russell.Stanford.EDU>
A reminder to those of you who have not sent brief descriptions. All we want
is 4-6 lines with a few phrases describing research interests, and a very
short list of two or three selected publications or other related activities.
Thanks
Helen
-------
∂12-Sep-88 0841 X3J13-mailer Availability of the standard
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 12 Sep 88 08:41:27 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA25711; Mon, 12 Sep 88 08:40:11 PDT
Message-Id: <8809121540.AA25711@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 12 Sep 88 11:33
To: x3j13@sail.stanford.edu
Subject: Availability of the standard
For you information:
A copy of the phase 1 standard (CLtL only) is available on
hudson.dec.com, username: ftp_user, password: ftppleasework.
This copy is VERY preliminary. Please do not spend time reviewing
this information because it will change shortly.
At the completion of phase 2, comments from the X3J13 committee
will be accepted. At this time, only comments from the editorial
committee are being processed.
kathy chapman
∂12-Sep-88 0938 DELAGI@SUMEX-AIM.Stanford.EDU [Dennis Gannon <gannon@iuvax.cs.indiana.edu>:]
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Sep 88 09:38:26 PDT
Date: Mon, 12 Sep 88 09:31:09 PDT
From: Bruce A. Delagi <DELAGI@SUMEX-AIM.Stanford.EDU>
Subject: [Dennis Gannon <gannon@iuvax.cs.indiana.edu>:]
To: aap@SUMEX-AIM.Stanford.EDU
Message-ID: <12430000336.25.DELAGI@SUMEX-AIM.Stanford.EDU>
Return-Path: <fpst@hubcap.clemson.edu>
Received: from RELAY.CS.NET by SUMEX-AIM.Stanford.EDU with TCP; Mon, 12 Sep 88 05:31:15 PDT
Received: from hubcap.clemson.edu by RELAY.CS.NET id aa23372; 12 Sep 88 8:04 EDT
Received: by hubcap.clemson.edu; Mon, 12 Sep 88 07:59:05 edt
Date: Mon, 12 Sep 88 07:59:05 edt
Message-Id: <8809121159.AA25700@hubcap.clemson.edu>
To: DELAGI%SUMEX-AIM.Stanford.EDU@RELAY.CS.NET,
coraki!pratt%Sun.COM@RELAY.CS.NET, cvb%daresbury.ac.uk@RELAY.CS.NET,
develo%waikato.ac.nz@RELAY.CS.NET, dwk%cs.tufts.edu@RELAY.CS.NET,
gopalakr%enuxha.asu.edu@RELAY.CS.NET,
hcube-users%hamlet.caltech.edu@RELAY.CS.NET,
hcube-users%mtu.edu@RELAY.CS.NET,
mcdonaldi%comsci.ua.oz%uunet.UU.NET@RELAY.CS.NET,
prasanna%usc-cse.usc.edu@RELAY.CS.NET,
scherrer%lovada.dec.com@RELAY.CS.NET
Newsgroups: comp.parallel
From: Dennis Gannon <gannon@iuvax.cs.indiana.edu>
Subject: 1989 Int. Conf. on Supercomputing
Approved: parallel@hubcap.clemson.edu
CALL FOR PAPERS
ICS-89: 1989 INTERNATIONAL CONFERENCE ON SUPERCOMPUTING
June 5-9,Crete, Greece
Conference Co-Chairmen
George Paul, IBM USA T. Papatheodorou, CTI Greece
Program Committee Directors
D. Gannon, Indiana Co-Chairman
E. N. Houstis, Purdue Co-Chairman
F. Hossfeld, KFA Chairman Europe and Africa
Y. Muraoka, Waseda Chairman Japan and Far East
J. Sopka, DEC Chairman North and South America
The International Conference on Supercomputing is now soliciting papers
for its third year. The proceedings, published by Springer-Verlag in
1987 and ACM in 1988 will again be published by ACM in 1989. Papers
are solicited in the following areas.
Applications of Supercomputing including:
Computational Mechanics, Fluid Dynamics and Astronomy,
Simulation and Modeling from Physics, Chemistry and Biology,
Artificial Intelligence and Symbolic Computation,
Graphics and Visualization,
Mathematical Software, Numerical Algorithms and Theoretical Studies.
Software Systems including:
Operating Systems,
Parallel Languages, Compilers and Automatic Parallelization Tools,
Performance Evaluation Tools, Methods and Modeling,
Programming Environments and Hight Level Problem Solving Systems.
Architecture:
MIMD, SIMD and Data Flow Systems Architectures,
Memory System Design (Distributed, Shared or Hierarchial),
Bus, Network and Communication Systems,
Instruction Architecture (RISC, CISC, etc.) and Performance Studies.
Authors should send five (5) copies of the manuscript to the program
chairman of their region. The deadline for submissions is January 10,1989.
Authors will be notified of acceptance by March 10. The addresses for
submissions are:
Europe and Africa: North and South America: Japan and Far East:
Dr. Friedel Hossfeld John. R. Sopka Dr. Yoichi Muraoka
KFA Julich Digital Equipment Corp. Dept. of Electrical Eng.
ZAM 110 Spit Brook Road Waseda University
Postfach 1913 Nashua, New Hampshire 3-4-1 Okubo, Shinjuku-ku
D-5170 Julich zip: 03062-2698 Tokyo, Japan
Fed. Rep. of Germany USA
A full list of invited speakers and program committee members will
follow on a later posting.
-------
∂12-Sep-88 1344 X3J13-mailer Common Lisp Mailing Lists
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I intend to stop maintaining the various Common Lisp mailing lists
(including X3J13) by the end of this year. I would like someone else to
take over my duties (which I have performed since 1981). Because the SAIL
computer will be de-commissioned within 1 year from now, the lists will
need to move anyway.
-rpg-
∂12-Sep-88 1954 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 12 Sep 88 19:54:09 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00892g; Mon, 12 Sep 88 18:52:49 PST
Received: by bhopal id AA02266g; Mon, 12 Sep 88 19:52:12 PDT
Date: Mon, 12 Sep 88 19:52:12 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809130252.AA02266@bhopal>
To: Masinter.pa@Xerox.COM
Cc: X3J13@Sail.stanford.edu, Masinter.pa@Xerox.COM
In-Reply-To: Masinter.pa@Xerox.COM's message of 4 Sep 88 13:39 PDT <880904-133941-8818@Xerox>
Subject: Issue: FUNCTION-TYPE (version 12)
There are several gaffs in this version, and I don't remember the previous
versions well enough to know if they are recently introduced or have been
around since the beginning. In fact, until the June 1988 X3J13 meeting, the
whole issue was divided enough (because of the coercion issue) that minor
gaffs like those pointed out below were not worth bothering about.
re: 5c. The motivation for this distinction between FUNCTION and
SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
use within programs while SYMBOL-FUNCTION is a data structure
accessor used primarily for meta-level applications and not
recommended for general use. It is provided primarily to
complete the set of accessors on symbols.
Surely the distinction between FUNCTION and SYMBOL-FUNCTION is the access
to lexical redefinitions, versus access restricterd to the global database
(the symbol-function attributes of all symbols). I *** would not *** try
to discourage use of, nor disparage, the SYMBOL-FUNCTION function. Further-
more, this isn't the time nor the place to debate the issue of how symbols
are implemented -- *must* they really be implemented as little structures,
or could their "attributes" be done other ways? There is no need to relegate
SYMBOL-FUNCTION to a set of "accessors on symbols", nor to bring up that
red-herring at all.
re: 6a. (COERCE symbol 'FUNCTION) extracts the SYMBOL-FUNCTION of the
given symbol, signalling an error if the symbol is not FBOUNDP or
if the symbol names a macro or a special-form.
"Extracts" seems a bit rude here; other documentary places probably would
just have said "returns the symbol-function of the given symbol", assuming
that the notion of a symbol having a 'symbol-function' attribute is already
well understood. A very similar issue is the accessing of the global value
of a variable -- one would talk about the symbol-value of the variable.
re: 6b. (COERCE x 'FUNCTION), where the value of x is a list that
begins with LAMBDA, will return a FUNCTION similar to
(EVAL '(FUNCTION ,x)).
It's surely bassackwards to describe what COERCE does by having to resort
to what EVAL does. Why not, for example, describe it in terms of what
(FUNCTION <x>) *** compiles into ***? On the contrary -- rather than
depending on an uncertain definition of either EVAL or COMPIL -- wouldn't
it be much cleaner (and clearer) to let FUNCTION be "primary", and then
document this case of COERCE in terms of what FUNCTION does. E.g.:
6b. (COERCE x 'FUNCTION), where the value of x is a list of form
(LAMBDA ...), will return a closure that is the functional
interpretation of x in the null lexical environment (see
CLtL, p87). If x is a list not of this form, an error
is signalled. [Note: a closure is always a function.]
This leaves out the issue of whether it's EVAL's action, or COMPILE's action,
that is the defining term. Unless these "actions" are sidestepped, then
it would be impossible to define this function unless EVAL were sufficiently
elaborated in the standard [e.g., such as Henry Lieberman's Common EVAL
proposal would do].
Under "Aesthetics:", the discussion is again not easy to follow.
re: Lambda-expressions do not obey the normal, apparent scoping rules because
free variables cannot refer to lexical bindings. This is because
coercing a list to a function would mean (EVAL `(FUNCTION ,list)).
I honestly don't know what this is trying to say. If it is trying to
highlight the difference between the interpretations of:
(QUOTE (LAMBDA ...))
and
(FUNCTION (LAMBDA ...))
then I certainly didn't get that from reading this paragraph [but rather
from a belief that this issue should be explicitly stated somewhere in the
proposal].
re: Making the coercion of lambda-expressions to functions explicit with
the use of EVAL will encourage less confusing code and also highlight
that use of EVAL.
Again, isn't this completely backwards? The whole point of this cleanup
issue to to *** stop *** programmers from writing "quotified" lambda
expressions, and to strongly encourage them to use "real" functions
instead. I'm sure we don't need to encourage the use of EVAL!
-- JonL --
∂13-Sep-88 0841 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Sep 88 08:41:23 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 13 Sep 88 11:38:00 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 13 Sep 88 11:39:06 EDT
Date: Tue, 13 Sep 88 11:39 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: FUNCTION-TYPE (version 12)
To: Jon L White <jonl@lucid.com>
Cc: Masinter.pa@xerox.com, X3J13@sail.stanford.edu
In-Reply-To: <8809130252.AA02266@bhopal>
Message-Id: <19880913153928.7.BARMAR@OCCAM.THINK.COM>
Date: Mon, 12 Sep 88 19:52:12 PDT
From: Jon L White <jonl@lucid.com>
Further-
more, this isn't the time nor the place to debate the issue of how symbols
are implemented -- *must* they really be implemented as little structures,
or could their "attributes" be done other ways? There is no need to relegate
SYMBOL-FUNCTION to a set of "accessors on symbols", nor to bring up that
red-herring at all.
Whether symbols are actually implemented as structures, they are
conceptually structures with several slots.
re: 6b. (COERCE x 'FUNCTION), where the value of x is a list that
begins with LAMBDA, will return a FUNCTION similar to
(EVAL '(FUNCTION ,x)).
It's surely bassackwards to describe what COERCE does by having to resort
to what EVAL does. Why not, for example, describe it in terms of what
(FUNCTION <x>) *** compiles into ***? On the contrary -- rather than
depending on an uncertain definition of either EVAL or COMPIL -- wouldn't
it be much cleaner (and clearer) to let FUNCTION be "primary", and then
document this case of COERCE in terms of what FUNCTION does. E.g.:
6b. (COERCE x 'FUNCTION), where the value of x is a list of form
(LAMBDA ...), will return a closure that is the functional
interpretation of x in the null lexical environment (see
CLtL, p87). If x is a list not of this form, an error
is signalled. [Note: a closure is always a function.]
This leaves out the issue of whether it's EVAL's action, or COMPILE's action,
that is the defining term. Unless these "actions" are sidestepped, then
it would be impossible to define this function unless EVAL were sufficiently
elaborated in the standard [e.g., such as Henry Lieberman's Common EVAL
proposal would do].
We debated long and hard at the last meeting to get the wording of this
particular clause, although I think it was mostly over the phrase that
finally turned into "similar to" (I think I originally wrote "equivalent
to", but people weren't sure what kind of equivalence it implied).
First of all, not all implementations will bother creating a closure for
a function that is in the null lexical environment (Symbolics doesn't),
so it would be wrong to specify that it returns a closure.
The reason this particular form was used as the definition is that the
justification given in the previous versions of the proposal, which
lacked this explicit coercion mechanism, was that this conversion could
be done by calling (EVAL '(FUNCTION x)). Therefore, we decided to
codify that particular idiom.
Since most uses of (COERCE <lambda-exp> 'FUNCTION) will not have a
constant <lambda-exp> (because then #'<thing> could have been used), I
think it is pretty unlikely to be compiled, although there is nothing
preventing it. By the same token, there's nothing preventing (EVAL
`(FUNCTION ,<lambda-exp>)) from compiling the function, either. They
really are equivalent at the language level.
barmar
∂13-Sep-88 0946 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Faculty Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Sep 88 09:46:03 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 13 Sep 88 09:39:46-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA06929; Tue, 13 Sep 88 09:09:01 PDT
Date: Tue, 13 Sep 1988 9:08:57 PDT
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score
Cc: chandler@polya.Stanford.EDU
Subject: Faculty Meeting
Message-Id: <CMM.0.87.590170138.chandler@polya.stanford.edu>
There will be a faculty meeting held in room 146 of MJH on September 27, 1988
at 2:30 - 4:30. Please send me any items you would like to have put on the
agenda.
∂13-Sep-88 0950 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Faculty Lunches
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Sep 88 09:50:49 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 13 Sep 88 09:40:43-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA08076; Tue, 13 Sep 88 09:40:35 PDT
Date: Tue, 13 Sep 1988 9:40:33 PDT
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score, jle@pescadero
Cc: chandler@polya.Stanford.EDU
Subject: Faculty Lunches
Message-Id: <CMM.0.87.590172033.chandler@polya.stanford.edu>
Hi all. Hope you've all had a great summer. The new academic year is
creeping up on us ... and the first weekly faculty lunch is scheduled for
Tuesday, September 29, at 12:00 in MJH-146. Looking forward to seeing you
all there.
∂13-Sep-88 1001 @Score.Stanford.EDU:chandler@polya.Stanford.EDU ["Joyce R. Chandler" <chandler@polya.stanford.edu> : Faculty Lunches
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Sep 88 10:01:02 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 13 Sep 88 09:56:21-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA08884; Tue, 13 Sep 88 09:56:14 PDT
Date: Tue, 13 Sep 1988 9:56:11 PDT
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score
Subject: ["Joyce R. Chandler" <chandler@polya.stanford.edu> : Faculty Lunches
]
Message-Id: <CMM.0.87.590172971.chandler@polya.stanford.edu>
Whoops....the date for the first faculty lunch is September 27....sorry.
---------------
Return-Path: <@Score.Stanford.EDU:chandler@polya.Stanford.EDU>
Received: from Score.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA08401; Tue, 13 Sep 88 09:48:49 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 13 Sep 88 09:40:43-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA08076; Tue, 13 Sep 88 09:40:35 PDT
Date: Tue, 13 Sep 1988 9:40:33 PDT
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score, jle@pescadero
Cc: chandler@polya.Stanford.EDU
Subject: Faculty Lunches
Message-Id: <CMM.0.87.590172033.chandler@polya.stanford.edu>
Hi all. Hope you've all had a great summer. The new academic year is
creeping up on us ... and the first weekly faculty lunch is scheduled for
Tuesday, September 29, at 12:00 in MJH-146. Looking forward to seeing you
all there.
∂13-Sep-88 1006 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Faculty Lunches
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Sep 88 10:06:20 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 13 Sep 88 10:00:40-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA09142; Tue, 13 Sep 88 10:00:31 PDT
Date: Tue, 13 Sep 1988 10:00:29 PDT
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score, jle@pescadero
Cc: chandler@polya.Stanford.EDU
Subject: Faculty Lunches
Message-Id: <CMM.0.87.590173229.chandler@polya.stanford.edu>
To correct previous message, first faculty lunch will be Tuesday, September 27.
∂13-Sep-88 1139 X3J13-mailer Re: Issue: FUNCTION-TYPE (version 12)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Sep 88 11:39:06 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 SEP 88 11:29:28 PDT
From: masinter.PA@Xerox.COM
Date: 13 Sep 88 11:27:26 PDT
Subject: Re: Issue: FUNCTION-TYPE (version 12)
In-reply-to: barmar@Think.COM's message of Tue, 13 Sep 88 11:39 EDT,
<19880913153928.7.BARMAR@OCCAM.THINK.COM>
To: Barry Margolin <barmar@Think.COM>
cc: Jon L White <jonl@lucid.COM>, Masinter.PA@Xerox.COM, X3J13@sail.stanford.edu
Message-ID: <880913-112928-3452@Xerox>
I'd just as soon lay this to rest. The cleanup issue writeups are intended
primarily for ourselves -- that we understand what we're voting on. The
proposals are intended for the editor and the editorial committee -- that they
understand the language they are describing. Certainly I would expect that the
language we use to describe how CLtL should change is not the same as the
language used to describe the language once changed.
If you have some suggestions for wording and terminology in the standard (and I
think the issues you both raise are valid), you should take them up with the
editor and the editorial committee (cl-editorial@sail.stanford.edu) and not the
committee of the whole.
Thanks,
Larry
∂13-Sep-88 1500 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Faculty Lunches
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Sep 88 15:00:52 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 13 Sep 88 14:41:40-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA20596; Tue, 13 Sep 88 13:39:22 PDT
Date: Tue, 13 Sep 1988 13:39:09 PDT
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score, jle@pescadero
Cc: chandler@polya.Stanford.EDU
Subject: Faculty Lunches
Message-Id: <CMM.0.87.590186349.chandler@polya.stanford.edu>
Two weeks vacation didn't do my mind any good....three times is the
charmer...
The faculty lunches are to be held at 12:15, not 12:00. Thanks.
∂13-Sep-88 1627 LOGMTC-mailer reminder: smith seminar tomorrow (wednesday)
Received: from Warbucks.AI.SRI.COM by SAIL.Stanford.EDU with TCP; 13 Sep 88 16:27:15 PDT
Date: Tue 13 Sep 88 15:53:39-PDT
From: WALDINGER@Warbucks.AI.SRI.COM (Richard Waldinger)
Subject: reminder: smith seminar tomorrow (wednesday)
To: aic-associates@Warbucks.AI.SRI.COM, csl-seminar@CSL.SRI.COM,
planlunch@Warbucks.AI.SRI.COM, logmtc@SAIL.STANFORD.EDU,
bboard@Warbucks.AI.SRI.COM, csd-bboard@SCORE.STANFORD.EDU
cc: smith@KESTREL.ARPA
Message-ID: <590194419.0.WALDINGER@WARBUCKS.AI.SRI.COM>
Mail-System-Version: <VAX-MM(229)+TOPSLIB(126)@WARBUCKS.AI.SRI.COM>
on the KIDS knowledge-based interactive software development system
at 4:15 wednesday, 14 september, in aic conferecλnce room, EJ228, sri international
visitors come early, get signed in
coffee at 3:45 in waldinger office.
-------
∂13-Sep-88 1627 LOGMTC-mailer reminder: smith seminar tomorrow (wednesday)
Received: from Warbucks.AI.SRI.COM by SAIL.Stanford.EDU with TCP; 13 Sep 88 16:27:15 PDT
Date: Tue 13 Sep 88 15:53:39-PDT
From: WALDINGER@Warbucks.AI.SRI.COM (Richard Waldinger)
Subject: reminder: smith seminar tomorrow (wednesday)
To: aic-associates@Warbucks.AI.SRI.COM, csl-seminar@CSL.SRI.COM,
planlunch@Warbucks.AI.SRI.COM, logmtc@SAIL.STANFORD.EDU,
bboard@Warbucks.AI.SRI.COM, csd-bboard@SCORE.STANFORD.EDU
cc: smith@KESTREL.ARPA
Message-ID: <590194419.0.WALDINGER@WARBUCKS.AI.SRI.COM>
Mail-System-Version: <VAX-MM(229)+TOPSLIB(126)@WARBUCKS.AI.SRI.COM>
on the KIDS knowledge-based interactive software development system
at 4:15 wednesday, 14 september, in aic conferecλnce room, EJ228, sri international
visitors come early, get signed in
coffee at 3:45 in waldinger office.
-------
∂14-Sep-88 0724 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Question on Combinator Reduction
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Sep 88 07:23:55 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA24466; Wed, 14 Sep 88 07:22:25 PDT
Message-Id: <8809141422.AA24466@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 14 Sep 88 07:23:32 PDT
Received: by BYUADMIN (Mailer X1.25) id 2603; Wed, 14 Sep 88 08:21:45 MDT
Date: Wed, 14 Sep 88 09:18:17 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Ronald J. Watro" <linus!watro%HUSC6.HARVARD.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Ronald J. Watro" <linus!watro%HUSC6.HARVARD.EDU@Forsythe.Stanford.EDU>
Subject: Question on Combinator Reduction
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Is there anywhere in the literature a correctness proof for
combinator reduction using the cyclic Y-rule, as described,
for example, in Peyton-Jones' book on implementing functional
languages? I have looked at several papers on Graph Rewriting,
including one by Barendregt et. al. in the 87 PARLE conference,
but I cannot find this result.
--
Dr. Ronald J. Watro The MITRE Corporation, MS A040, Burlington RD,
Bedford, MA 01730 USA 617-271-8390
ARPA: watro%linus@mitre-bedford.ARPA
UUCP: ...{decvax,utzoo,philabs,security,allegra,genrad}!linus!watro
∂14-Sep-88 0734 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Papers -- RTA-89
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Sep 88 07:34:21 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA24709; Wed, 14 Sep 88 07:32:57 PDT
Message-Id: <8809141432.AA24709@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 14 Sep 88 07:34:03 PDT
Received: by BYUADMIN (Mailer X1.25) id 2803; Wed, 14 Sep 88 08:31:37 MDT
Date: Wed, 14 Sep 88 09:20:38 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
nachum dershowitz <nachum%M.CS.UIUC.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: nachum dershowitz <nachum%M.CS.UIUC.EDU@Forsythe.Stanford.EDU>
Subject: Call for Papers -- RTA-89
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
RTA-89
CALL FOR PAPERS
Third International Conference on
Rewriting Techniques and Applications
April 3-5, 1989
Chapel Hill, North Carolina, U.S.A.
The third bi-annual Conference on Rewriting Techniques and
Applications will be held in Chapel Hill on April 3-5, 1989. Papers are
being solicited in any of the following or related areas:
Term rewriting systems Symbolic and algebraic computation
Conditional rewriting Equational programming languages
Graph rewriting and grammars Completion procedures
Algebraic semantics Rewrite-based theorem proving
Equational reasoning Unification and matching algorithms
Lambda and combinatory calculi Term-based architectures
Proceedings are planned for publication by Springer-Verlag as part of their
Lecture Notes in Computer Science series.
Both original research papers and state-of-the-art technical surveys are
solicited. Descriptions of new, implemented systems will also be
considered. All submissions should be clearly written in English and
include references and comparisons with related work, where appropriate.
(If a substantially similar paper has or will be submitted for publication
elsewhere, this fact must be noted in the cover letter.) Each submission
should include 10 (ten) copies of a full draft paper of no more than 15
(fifteen) double-spaced pages. (If a copier is unavailable to the author,
one copy will suffice.) Please include an electronic address, if
available. Submissions must reach the following address no later than
October 17, 1988:
Nachum Dershowitz, RTA-89
Department of Computer Science
University of Illinois at Urbana-Champaign
1304 West Springfield Ave. telephone: [+1] (217) 333-8879
Urbana, IL 61801-2987 Internet: nachum@a.cs.uiuc.edu
U.S.A. Bitnet: nachum@uiucvmd
Notification of acceptance or rejection by December 5, 1988.
Camera-ready copy (following special guidelines) due January 20, 1989.
Program Committee:
Bruno Courcelle (Bordeaux) Deepak Kapur (Albany)
Nachum Dershowitz (Urbana), Chair Claude Kirchner (Nancy)
Jean Gallier (Philadelphia) Jan Willem Klop (Amsterdam)
Jieh Hsiang (Stony Brook) Dallas Lankford (Ruston)
Jean-Pierre Jouannaud (Orsay) Mark Stickel (Menlo Park)
Local Arrangements Chair:
David A. Plaisted
Department of Computer Science
CB# 3175, 352 Sitterson Hall
University of North Carolina at Chapel Hill
Chapel-Hill, NC 27599-3175 telephone: [+1] (919) 962-1751
U.S.A. Internet: plaisted@cs.unc.edu
RTA-89 will be held on or near the campus of the University of North
Carolina in Chapel Hill. A block of rooms has been reserved at the
Carolina Inn near campus.
Chapel Hill, a town of about 40,000 in central North Carolina, blends a
mild climate, a relaxed southern atmosphere, and the charm of a college
town with such cultural advantages as excellent theater and music, an art
museum, and a planetarium. The Carolina beaches, Cape Hattaras, Great
Smoky Mountains National Park, and the Blue Ridge Mountains are only a few
hours away. North Carolina is known for its dogwoods, which are in bloom
in early April.
The University of North Carolina at Chapel Hill was the first state
university to open its doors in 1795, and currently enrolls approximately
22,000 students. The Computer Science Department has about 120 full-time
graduate students, and is particularly well known for its work in computer
graphics. In 1987 the Department moved into a new building, which has one
of the most advanced communications systems in the country. Together with
Duke University and North Carolina State University, UNC at Chapel Hill is
one of the vertices of the Research Triangle, a rapidly growing cluster of
laboratories and start-up companies. A number of major corporations have
facilities at the nearby Research Triangle Park, one of the nation's
largest and most successful research centers. The Microelectronics Center
of North Carolina (MCNC) is also located at the Research Triangle Park.
Previous meetings were held in Dijon (1985) and Bordeaux (1987); their
proceedings were also published by Springer.
Further details and the final program will be sent to anyone submitting a
paper or otherwise expressing interest in the meeting.
****************************** PLEASE POST ******************************
∂14-Sep-88 0959 @Score.Stanford.EDU:chandler@polya.Stanford.EDU NSF
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Sep 88 09:59:15 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 14 Sep 88 09:55:11-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA00345; Wed, 14 Sep 88 09:54:55 PDT
Date: Wed, 14 Sep 1988 9:54:40 PDT
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score
Subject: NSF
Message-Id: <CMM.0.87.590259280.chandler@polya.stanford.edu>
This is to let you know that I have the National Science Foundation's current
program announcement and guideline booklet entitled UNDERGRADUATE FACULTY
ENHANCEMENT PROGRAM. In the introduction it states "This announcement
describes the UNDERGRADUATE FACULTY ENHANCEMENT PROGRAM, which makes grants
for Undergraduate Faculty Seminars and Conferences. These provide
opportunities for groups of faculty to learn about new techniques and new
developments in their fields."
I have this booklet in my office and you are welcome to come by and look at
it if you wish.
jc
∂15-Sep-88 0225 X3J13-mailer "passed" cleanup issues
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Sep 88 02:25:29 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 88 01:35:24 PDT
Date: 15 Sep 88 01:35 PDT
From: masinter.pa@Xerox.COM
Subject: "passed" cleanup issues
To: x3J13@sail.stanford.edu
reply-to: Masinter.pa@Xerox.COM
Message-ID: <880915-013524-2103@Xerox>
The cleanup issues passed at previous meetings of X3J13 are now available for
anonymous FTP from host arisia.xerox.com (address 13.1.100.206). The files are
plain text, although some of the files may be missing line-breaks. If you do not
have network access, I can mail you copies of any issue.
I will be making text of the pending issues available in the same way.
user anonymous, any password will do.
The passed issues on the directory clcleanup/passed.
I will be making the text of pending issues available in the same way, in the
directory clcleanup/pending.
ftp arisia.xerox.com
Connected to arisia.
220 arisia FTP server (Version 4.15 Sat Nov 7 15:24:41 PST 1987) ready.
Name (arisia.xerox.com:masinter): anonymous
331 Guest login ok, send ident as password.
Password:
230 Guest login ok, access restrictions apply.
ftp> cd clcleanup/passed
ftp> ls
200 PORT command okay.
150 Opening data connection for /bin/ls (13.1.100.218,1029) (0 bytes).
adjust-array-displacement
adjust-array-fill-pointer
append-dotted
aref-1d
assoc-rassoc-if-key
colon-number
compiler-warning-stream
data-types-hierarchy-underspecified
declare-macros
defstruct-slots-constraints-number
defvar-documentation
defvar-init-time
defvar-initialization
disassemble-side-effect
do-symbols-duplicates
dribble-technique
flet-declarations
flet-implicit-block
format-atsign-colon
format-colon-uparrow-scope
format-comma-interval
format-op-c
function-type
function-type-key-name
get-setf-method-environment
import-setf-symbol-package
keyword-argument-name-package
last-n
macro-function-environment
princ-character
push-evaluation-order
reduce-argument-extraction
shadow-already-present
sharpsign-plus-minus-package
226 Transfer complete.
767 bytes received in 2.3 seconds (.32 Kbytes/s)
∂15-Sep-88 1559 DELAGI@SUMEX-AIM.Stanford.EDU ["Marc Abrams" <marc@pescadero.stanford.edu>: New mailing list on parallel simulation technical discussion]
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Sep 88 15:59:27 PDT
Date: Thu, 15 Sep 88 15:31:48 PDT
From: Bruce A. Delagi <DELAGI@SUMEX-AIM.Stanford.EDU>
Subject: ["Marc Abrams" <marc@pescadero.stanford.edu>: New mailing list on parallel simulation technical discussion]
To: aap@SUMEX-AIM.Stanford.EDU
Message-ID: <12430852424.44.DELAGI@SUMEX-AIM.Stanford.EDU>
1
---------------
Return-Path: <marc@Pescadero.stanford.edu>
Received: from Pescadero by SUMEX-AIM.Stanford.EDU with TCP; Thu, 15 Sep 88 11:14:08 PDT
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA00163; Thu, 15 Sep 88 11:19:51 PDT
Date: Thu, 15 Sep 88 11:19:51 PDT
From: "Marc Abrams" <marc@pescadero.stanford.edu>
Message-Id: <8809151819.AA00163@Pescadero>
To: ag@pepper.Stanford.EDU, delagi@sumex-aim.Stanford.EDU,
lazowska@krakatoa.cs.washington.edu, soule@gurgi.Stanford.EDU,
wagner@june.cs.washington.edu
Subject: New mailing list on parallel simulation technical discussion
Cc: hitson@Pescadero.stanford.edu, marc@Pescadero.stanford.edu
A mailing list has been created by Bruce Hitson called:
parsim@pescadero.stanford.edu
Its purpose is for technical discussion on parallel simulation. We
expect that contributors to the list are actively developing, implementing,
and/or experimenting with discrete event parallel simulation algorithms.
Currently we intend to use the list to:
* propose benchmarks
* compare implementations that each of us have on each other's benchmarks
* provide fast communication of preliminary results
* discuss implementation details
* foster joint work
The current participants are myself and Bruce (at stanford), Henry Sowizral
(riacs), and Dan Friedman (BBN). Currently Bruce, Henry, and I are exchanging
the queueing network benchmark I use (based on Reed, Malony, McCredie) and
the Game of Life that Henry uses to compare the data we've collected for each
of our own implementations of Time-warp.
The mail list is intended for active participation.
To join please send a request to the mailing list name that includes a brief
statement of what you currently work on or plan to do.
------- End of Unsent Draft
-------
∂15-Sep-88 1617 X3J13-mailer additional passed clean-up issues
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Sep 88 16:17:35 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 88 15:42:33 PDT
Date: 15 Sep 88 15:42 PDT
From: masinter.pa@Xerox.COM
To: X3J13@Sail.stanford.edu
Subject: additional passed clean-up issues
reply-to: Masinter.pa@Xerox.COM
Message-ID: <880915-154233-3261@Xerox>
It was pointed out that I missed some passed issues:
PATHNAME-STREAM
PATHNAME-SYMBOL
I can't find a record of this issue being voted on:
SUBSEQ-OUT-OF-BOUNDS
It was distributed before the June 1988 meeting. I will include it in the set of
pending issues unless someone has a record of it being accepted already.
∂15-Sep-88 1646 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Abstracts -- International Conference on Algebraic
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Sep 88 16:46:35 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA08817; Thu, 15 Sep 88 15:36:11 PDT
Message-Id: <8809152236.AA08817@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 15 Sep 88 15:37:14 PDT
Received: by BYUADMIN (Mailer X1.25) id 6393; Thu, 15 Sep 88 15:46:57 MDT
Date: Thu, 15 Sep 88 10:33:32 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Chic Rattray <cr%CS.STIR.AC.UK@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Chic Rattray <cr%CS.STIR.AC.UK@Forsythe.Stanford.EDU>
Subject: Call for Abstracts -- International Conference on Algebraic
Methodology
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
CALL FOR ABSTRACTS
International Conference on
Algebraic Methodology And Software Technology, AMAST
Iowa City, Iowa, May 22-24, 1989
The goal of the conference is to consolidate the trend of
using algebraic methodology as a foundation for software
technology showing that universal algebra provides a practi-
cal mathematical alternative to ad hoc approaches used in
software development. Both academia and industry are the
beneficiary of such a formal foundation.
In order to achieve this goal, we plan to bring together
leading researchers in mathematics and computer science on a
common platform so that algebraic methodologies that can be
used as a viable alternative to ad hoc approaches for
software development can be identified and the appropriate-
ness of such alternatives in view of actual implementations
can be discussed.
Talks reporting research in algebra suitable as a foundation
for software technology as well as software technologies
developed by means of algebraic methodologies are welcome.
We invite you to submit a two page abstract (including a few
citations of relevant work) of your talk to the address
AMAST CONFERENCE
Computer Science and Mathematics Departments
The University of Iowa
Iowa City, IA 52242, U.S.A.
The submissions must be received by February 1, 1989 and the
notifications of acceptance will be sent by March 15, 1989.
The authors should include a return postal address and an
electronic mail address if it is available.
A special issue of the journal ``Theoretical Computer Sci-
ence'' will be dedicated to this conference and each parti-
cipant will be invited to submit a full paper for publica-
tion. Further information can be obtained from:
In Canada: In Europe: In U.S.A:
========================================================================
Prof. Dan Ionescu Prof. Maurice Nivat Prof. Eugene Madison, Math.
University of Ottawa Universite Paris Prof. Teodor Rus, Comp.Sci.
Department of& 2, Place Jussieu University of Iowa
Electrical Engineering 75005 Paris, France Iowa City, IA 52242
770 King Edward, OTTAWA Phone: (1) 43259874 Phone: (319)-335-0694
Ont. Canada K1N 6N5 e-mail:
Phone: (613)-564-2211 rus@herky.cs.uiowa.edu
∂16-Sep-88 0721 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Candidates
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Sep 88 07:21:12 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA26800; Fri, 16 Sep 88 07:18:51 PDT
Message-Id: <8809161418.AA26800@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 16 Sep 88 07:19:54 PDT
Received: by BYUADMIN (Mailer X1.25) id 4904; Fri, 16 Sep 88 08:17:54 MDT
Date: Fri, 16 Sep 88 09:11:55 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"David S. Johnson" <dsj@RESEARCH.ATT.COM>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "David S. Johnson" <dsj@RESEARCH.ATT.COM>
Subject: Call for Candidates
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
*** CALL FOR CANDIDATES ***
SIGACT will be having its semi-annual elections next Spring,
and now is the time for would-be candidates to identify
themselves to the Nominating Committee, chaired by Zvi Galil
of the Department of Computer Science, Columbia University, New York,
NY 10027 (and past SIGACT Chair).
The 5 positions that will be contested are:
Chair
Vice-Chair
Secretary-Treasurer
2 Members-at-Large
To qualify, you must be a member of SIGACT and ACM and be prepared
to do some work on behalf of the organization (especially in the
top three jobs).
SIGACT's success depends on the quality and energy of its leadership, and
we are always looking for new faces, so if you would like to get involved,
please let Zvi know. His email address is galil@cs.columbia.edu,
his phone number is 212-280-8191, or you can talk to him directly at
the upcoming FOCS meeting in White Plains.
*********************************************************************
(P.S.: Under another recently acquired hat, Zvi is also now accepting
submissions to the JOURNAL OF ALGORITHMS, where he has replaced
Herb Wilf as managing editor.)
∂16-Sep-88 0726 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu CALL FOR PAPERS - WADS '89
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Sep 88 07:26:51 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA26955; Fri, 16 Sep 88 07:24:29 PDT
Message-Id: <8809161424.AA26955@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 16 Sep 88 07:25:32 PDT
Received: by BYUADMIN (Mailer X1.25) id 4977; Fri, 16 Sep 88 08:23:26 MDT
Date: Fri, 16 Sep 88 09:19:01 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Frank Dehne <DEHNE%CARLETON.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Frank Dehne <DEHNE%CARLETON.BITNET@forsythe.stanford.edu>
Subject: CALL FOR PAPERS - WADS '89
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-----------------------------------------------------------------------
CALL FOR PAPERS
Workshop on Algorithms
and Data Structures
August 16-18, 1989
Carleton University
Ottawa, Canada
The Workshop, which continues the 1988 Scandinavian Workshop on
Algorithm Theory, is intended as a forum for researchers in the area of
design and analysis of algorithms and data structures.
We invite submissions of papers presenting original research on
algorithms and data structures in all areas, including combinatorics,
computational geometry, databases, graphics, parallel and distributed
computing. Contributors are invited to send 4 copies of a full paper
(not exceeding 12 pages) to
Workshop on Algorithms and Data Structures
School of Computer Science
Carleton University
Ottawa, Canada K1S 5B6
tel.: (613) 564-7545, e-mail: workshop@carleton.bitnet
Submissions must arrive before March 15, 1989. Authors will be notified
of acceptance or rejection by April 30, 1989. Proceedings will be
published, possibly in the Springer Verlag series Lecture Notes in
Computer Science. The final versions of accepted papers must arrive in
camera-ready form before May 25, 1989, to ensure the availability of the
proceedings at the conference.
Invited Speakers:
Michael Atallah (Purdue), Luc Devroye (McGill), Herbert Edelsbrunner
(Urbana Champaign), Gaston Gonnet (Waterloo), Jan van Leeuwen (Utrecht),
Chee Yap (Courant Institute).
Program Committee:
Selim Akl (Queen's), Frank Dehne (Carleton), Greg Fredrickson (Purdue),
David Kirkpatrick (UBC), Andrzej Lingas (Linkoeping), Kurt Mehlhorn (U.
des Saarlandes), Ian Munro (Waterloo), Joerg-Ruediger Sack (Carleton),
Nicola Santoro (Carleton), Esko Ukkonen (Helsinki), Jorge Urrutia
(Ottawa), Derick Wood (Waterloo).
Organizing Committee:
Frank Fiala, John Oommen, Ekow Otoo (Carleton), Robert Probert (Ottawa).
-----------------------------------------------------------------------
∂16-Sep-88 0943 DELAGI@SUMEX-AIM.Stanford.EDU [gul agha <agha-gul@YALE.ARPA>: Conference Particulars]
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Sep 88 09:43:00 PDT
Date: Fri, 16 Sep 88 09:36:27 PDT
From: Bruce A. Delagi <DELAGI@SUMEX-AIM.Stanford.EDU>
Subject: [gul agha <agha-gul@YALE.ARPA>: Conference Particulars]
To: aap@SUMEX-AIM.Stanford.EDU, soule@gurgi.Stanford.EDU
Message-ID: <12431049878.12.DELAGI@SUMEX-AIM.Stanford.EDU>
Return-Path: <agha-gul@YALE.ARPA>
Received: from CELRAY.CS.YALE.EDU by SUMEX-AIM.Stanford.EDU with TCP; Fri, 16 Sep 88 07:43:04 PDT
Received: by CELRAY.CS.YALE.EDU; Fri, 16 Sep 88 10:37:48 EDT
Date: Fri, 16 Sep 88 10:37:48 EDT
From: gul agha <agha-gul@YALE.ARPA>
Full-Name: gul agha
Message-Id: <8809161437.AA09525@CELRAY.CS.YALE.EDU>
To: DELAGI@SUMEX-AIM.Stanford.EDU
In-Reply-To: Bruce A. Delagi's message of Thu, 15 Sep 88 15:40:02 PDT <12430853923.44.DELAGI@SUMEX-AIM.Stanford.EDU>
Subject: Conference Particulars
Bruce,
Strange! I did check the records and something should have gone out to
you. Anyway, here it is...
Cheers,
Gul
-----------------
WORKSHOP ON OBJECT-BASED CONCURRENT PROGRAMMING
Sheraton on Harbor Island, San Diego
(In Conjunction with OOPSLA '88)
September 26-27, 1988
(Provisional Program)
Note: Participation is by invitation only. I am posting this for
general interest. A special February 1989 issue of the SIGPLAN
Notices will publish research summaries from the workshop.
MONDAY SEPT 26
8.30 am: Registration
9.00-10.00 am: PANEL. Research Directions in Object-Based Concurrent
Programming (Panelists: Gul Agha, Aki Yonezawa, Peter Wegner)
10.30-12.30: Session 1. Chair: Peter Wegner, Brown U.
"Linearizable Concurrent Objects"
Maurice Herlihy and Jeanette Wing, Carnegie-Mellon U.
"Two Models of Concurrent Objects"
Oscar Nierstrasz, U. de Geneve, Switzerland
"A Protocol Constrained Language"
Jan Van Den Bos, Leiden U., Netherlands
"A Model for a Reflective Object-Oriented Language"
Yves Caseau, Bell Core
"A Synchronization Mechanism for Typed Objects in a Distributed System"
D. Decouchaut, M. Meysembourg, S. Krakowiak, M. Riveill, X. Rousset de Pina,
Lab de Genie Informatique, France
12:30 - 2:00: Lunch
2:00 - 4:00: Session 2. Chair: Aki Yonezawa, Tokyo Inst. of Tech.
"Cantor: An Actor Programming System"
W. Athas and N. Jackson, Caltech
"Concurrent Meld"
Gail Kaiser, Columbia U.
"Parallel Objects on Distributed Constraint Logic Programming Machines"
John Koegel, U. Lowell
"Extensions to the Object-Paradigm for Distributed Applications"
L. Heuser, M. Mullhauser, and A. Schill, U. Karlsruhe and DEC, W. Germany
"Language Issues in the Design of Concurrent Systems"
Martin Feather, U. Southern California
4:30-5:30 PANEL. Languages and Models for Concurrent Object-Based
Programming (Panelists to be announced)
7:30-10:00: Working Groups (to be determined by participants)
Possible topics for working groups:
Models for Concurrent Object-Based Programming
Reflection and Object-Based Concurrency
Verification of Concurrent Object-Based Programs
Multiparadigm Systems
TUESDAY, SEPT 27
9:00 - 10:00 am: Report of Working Groups
10:30 - 12:30: Session 3. Chair: Gul Agha, Yale U.
"Design of a Distributed Implementation of ABCL"
Jean Pierre Briot and Jean DeRatuld, U. Paris VI, France
"Distributed Concurrent Smalltalk: A Language and System for the
Interpersonal Environment"
Tatsuo Nakajima, Yasuhiko Yokote, Mario Tokoro, Shinichi Ochiai and
Tatsuo Nagamatsu, Keio U., Japan
"The Ubik Configurator: A Fusion of Messages, Daemons, and Rules"
Peter de Jong, M.I.T.
"Harmony as an Object-Oriented Operating System"
S. A. MacKay, W. M. Gentleman, D. A. Stewart, M. Wein,
National Research Council, Ottawa
"Elint in Lamina Application of a Concurrent Object"
Bruce Delagi and Nakul Saraiya, Stanford U.
2:00 - 4:00: Short Presentations
(To be announced)
4:30 - 5:30: PANEL. What have we learned? Where do we go from here?
(Panelists to be announced)
7:30: Conference Dinner
(Please RSVP)
-------
∂16-Sep-88 1145 X3J13-mailer agenda items please
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Sep 88 11:45:09 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA02073g; Fri, 16 Sep 88 10:43:32 PST
Received: by challenger id AA04779g; Fri, 16 Sep 88 11:41:19 PDT
Date: Fri, 16 Sep 88 11:41:19 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809161841.AA04779@challenger>
To: x3j13@sail.stanford.edu
Subject: agenda items please
If you have anything you wish to bring to a vote, please remember committee
member need to RECEIVE proposals 2 weeks before the meeting. (Mail early next
week.) Call Bob Mathis for mailing labels 703/359-0203.
Below is a rough draft of the agenda. Please let me know ASAP if you have
anything to add. See you soon!
---jan---
**************DRAFT**************
X3J13 Committee Meeting Agenda
October 11 - 12, 1988
1 Call to Order, October 11, 9:00am
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Character Subcommittee Report and Vote, Thom Linden (3 hrs)
6 Lunch, 12:00pm - 1:00pm
7 CLOS Workshop Report, Gregor Kiczales
8 Compiler Subcommittee Report and Vote, Sandra Loosemore (1.5 hrs)
9 Editorial Subcommittee Report, Kathy Chapman (30 minutes)
10 ??
11 Recess, 5:00pm
12 Call to Order, October 12, 9:00am
13 Clean-up, Larry Masinter
14 Lunch, 12:00pm - 1:00pm
15 Other committee reports
16 Adjournment, 5:00pm
Next X3J13 meeting: 1/16 - 1/18 1989 Kauai, Hawaii
∂16-Sep-88 1157 X3J13-mailer subcommittee meetings
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Sep 88 11:57:10 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA02080g; Fri, 16 Sep 88 10:55:43 PST
Received: by challenger id AA04785g; Fri, 16 Sep 88 11:53:30 PDT
Date: Fri, 16 Sep 88 11:53:30 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809161853.AA04785@challenger>
To: x3j13@sail.stanford.edu
Subject: subcommittee meetings
As you can see there is some overlap. Any other subcommittee meetings should
be scheduled on Sunday or Monday evening. Please let me know of any changes
or additions.
Subcommittee meetings
October 10, 1988
9:30 - 5:00 Characters (4-5)
9:30 - 12:30 Cleanup (?)
11:30 - 3:30 Editorial (?)
2:00 - 5:00 Compiler (?)
∂16-Sep-88 1158 @Score.Stanford.EDU:tajnai@polya.Stanford.EDU Important dates for 1989
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Sep 88 11:58:03 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 16 Sep 88 11:47:18-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA05170; Fri, 16 Sep 88 11:47:32 PDT
Date: Fri, 16 Sep 1988 11:47:30 PDT
Sender: "Carolyn E. Tajnai" <tajnai@polya.stanford.edu>
From: "Carolyn E. Tajnai" <tajnai@polya.stanford.edu>
To: faculty@polya.Stanford.EDU, csd@polya.Stanford.EDU, csl-everyone@sierra
Subject: Important dates for 1989
Message-Id: <CMM.0.87.590438850.tajnai@polya.stanford.edu>
Dates for 1989:
Monday, February 13, -- Prof. Ruzena Bajcsy, Chair of the
Computer Science Department at the Univ. of PA, will
present the first Forsythe Lecture (in the evening)
Tuesday, February 14 -- Prof. Bajcsy will present the second
Forsythe Lecture at the CS500 Seminar, 4:15 p.m.
6:00 -- Informal buffet supper for Forum
Wednesday, February 15 and
Thursday, February 16
The 21st Annual Meeting of the Computer Forum
∂17-Sep-88 1418 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Congrats!
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Sep 88 14:18:27 PDT
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sat 17 Sep 88 14:16:04-PDT
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA28669; Sat, 17 Sep 88 11:28:21 PDT
Date: Sat, 17 Sep 88 11:28:21 PDT
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8809171828.AA28669@Tenaya.stanford.edu>
To: faculty@score
Subject: Congrats!
Congratulations to Prof. Andrew Goldberg for having been awarded
the Tucker Prize!
Here is some information about the prize:
The A. W. Tucker Prize for an outstanding paper authored by a student
was established recently by the Mathematical Programming Society.
The first award will be made at the 13th International Symposium of
the Mathematical Programming Society to be held in Tokyo, August 29 --
September 2, 1988.
. . .
The paper and the work on which it is based should have been undertaken
and completed in conjunction with a degree program.
Andy's thesis "Efficient Graph Algorithms for
Sequential and Parallel Computers" won the award this year.
The Tucker Prize is a new one. Two other (older) prizes awarded by the
Society are the Dantzig Prize and the Fulkerson Prize. These prizes are
awarded tri-annually, in conjunction with the Symposium. This time,
Michael Todd (from Cornell) received the Dantzig Prize. Narendra Karmarkar
(Bell Labs) and Eva Tardos (MIT) shared the Fulkerson Prize.
∂19-Sep-88 1807 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Wulf Visit
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Sep 88 18:07:41 PDT
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 19 Sep 88 18:05:25-PDT
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA00101; Mon, 19 Sep 88 17:59:11 PDT
Date: Mon, 19 Sep 88 17:59:11 PDT
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8809200059.AA00101@Tenaya.stanford.edu>
To: faculty@score
Subject: Wulf Visit
Bill Wulf, head of NSF's Computer and Information Sciences and Engineering
Division will be visiting Stanford on Monday, Sept. 26 from 8 'til noon.
People who would like to see him during that time should let Joyce
Chandler (chandler@polya) know. I don't know Bill's exact schedule yet
(I'm talking with him by phone tomorrow), so I can't guarantee time
slots. Maybe some of the time would be better spent in a group
discussion. Stay tuned. -Nils
∂19-Sep-88 1857 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Sep 88 18:57:18 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03895g; Mon, 19 Sep 88 17:55:36 PST
Received: by bhopal id AA15915g; Mon, 19 Sep 88 18:55:04 PDT
Date: Mon, 19 Sep 88 18:55:04 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809200155.AA15915@bhopal>
To: barmar@Think.COM
Cc: Masinter.pa@xerox.com, X3J13@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Tue, 13 Sep 88 11:39 EDT <19880913153928.7.BARMAR@OCCAM.THINK.COM>
Subject: Issue: FUNCTION-TYPE (version 12)
re: First of all, not all implementations will bother creating a closure for
a function that is in the null lexical environment (Symbolics doesn't),
so it would be wrong to specify that it returns a closure.
See CLtL, p87: "If fn is a lambda-expression, then a ``lexical closure''
is returned, that is a function that when invoked will execute the body
of the lambda-expresssion in such a way as to observe the rules of
lexical scoping properly." This applies regardless of whether or not
the lexical environment is null.
What many persons miss is the fact that a perfectly ordinary compiled
function with a null lexical environment satisfies the definition of
"closure". Possibly they are misled, as you may have been, by the
fact that some vendors have a lower-level data-type that distinguishes
functions closed over the null lexical environment from those closed
over something more significant.
Incidentally, I thought this was a "Cleanup" subcommittee issue, and only
now notice that is beng cc'd to X3J13 as a whole. Was this a mistake?
-- JonL --
∂20-Sep-88 0241 @SUMEX-AIM.Stanford.EDU,@RELAY.CS.NET:OKUNO@ntt-20.ntt.jp [Revolving Seminar 9/22: Tom Knight]
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Sep 88 02:41:10 PDT
Received: from RELAY.CS.NET by SUMEX-AIM.Stanford.EDU with TCP; Tue, 20 Sep 88 02:35:23 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa13373; 20 Sep 88 4:50 EDT
Received: from ntt.jp by RELAY.CS.NET id ac18225; 20 Sep 88 4:38 EDT
Received: by ntt-sh.ntt.jp (3.2/ntt-sh-01) with TCP; Tue, 20 Sep 88 17:16:53 JST
Received: by MECL.NTT.jp (3.2/NTTcs02) with TCP; Tue, 20 Sep 88 17:15:15 JST
Date: Tue 20 Sep 88 17:11:43
From: Hiroshi Gitchang Okuno <Okuno@ntt-20.ntt.jp>
Subject: [Revolving Seminar 9/22: Tom Knight]
To: qlisp%gang-of-four.stanford.edu@ntt.jp,
aap%sumex-aim.stanford.edu@ntt.jp
Cc: soheiG@ntt-20.ntt.jp, sokanG@ntt-20.ntt.jp
Organization: NTT Software Laboratories
Group: New Unified Environments (NUE) Group
Project: Parallel Programming
Address: 3-9-11 Midori-cho, Musashino, Tokyo 180 JAPAN
Phone: +81 (422)59-3850
Message-Id: <12431995649.24.OKUNO@NTT-20.NTT.JP>
FYI,
- Gitchang -
-------------------- Forwarded Message --------------------
Date: Mon, 19 Sep 88 13:15:06 EDT
From: Barbara K. Moore <BARB@REAGAN.AI.MIT.EDU>
Subject: Revolving Seminar 9/22: Tom Knight
To: tech-sq@XX.LCS.MIT.EDU, ferrante@DSPVAX.MIT.EDU
Message-ID: <19880917164121.4.BARB@LENNON.AI.MIT.EDU>
========================================================================
AI REVOLVING SEMINAR
========================================================================
THURSDAY, SEPTEMBER 22, 1988
4:00 p.m.
8TH FLOOR PLAYROOM, MIT AI LAB
What Computer Architects Should Do Next
-or-
Specialization is for Insects
Tom Knight
The chaos of the last decade in parallel computer architecture
is largely due to the premature specialization of parallel computer
architectures to particular programming models. The careful choice of
the correct primitives to support in hardware leads to a general purpose
parallel architecture which is capable of supporting a wide variety of
programming models.
This talk will show that low latency communication emerges as
the essential component in parallel processor design, and will
demonstrate how to use low latency communication to support other
programming models such as data level parallelism and coherent shared
memory in large processor arrays.
We are now designing a very low latency, high bandwidth, fault
tolerant communications network, called Transit. It forms the
communications infrastructure - the replacement of the bus - for a high
speed MIMD processor array which can be programmed using a wide variety
of models. Transit achieves its high performance through a combination
of techniques in many different disciplines.
The packaging of Transit is done using near isotropic density
three dimensional wiring, allowing much tighter packing of components,
and routing of wires on a 3-D grid. The network is direct contact
liquid cooled with Fluorinert. The use of custom VLSI pad drivers and
receivers provides very high speed signalling between chips. The
topology of the network provides self-routing, fault tolerant, short
pipeline delay communications between pairs of processors. And finally,
the design of the processor allows high speed message dispatching and
low latency context switch.
-------
∂20-Sep-88 0833 HEMENWAY@Score.Stanford.EDU Meeting Announcement
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Sep 88 08:33:36 PDT
Date: Tue 20 Sep 88 08:14:42-PDT
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Meeting Announcement
To: faculty@Score.Stanford.EDU
Message-ID: <12432083573.10.HEMENWAY@Score.Stanford.EDU>
At the June faculty meeting, it was decided that committee meetings should
be announced to the faculty as a whole. In that spirit, this is to report
that the MSCS Program Committee will have its first meeting of the year on
Tuesday, Sept. 27 at 1:15 in MJH 252.
Sharon
-------
∂20-Sep-88 1124 @Score.Stanford.EDU:chandler@polya.Stanford.EDU F.Y.I.
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Sep 88 11:24:41 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 20 Sep 88 11:22:15-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA08045; Tue, 20 Sep 88 11:21:37 PDT
Date: Tue, 20 Sep 1988 11:21:14 PDT
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score
Subject: F.Y.I.
Message-Id: <CMM.0.87.590782874.chandler@polya.stanford.edu>
I have in my office a book entitled THE NATIONAL CHALLENGE IN COMPUTER
SCIENCE AND TECHNOLOGY put out by the National Academy Press and available
from Computer Science and Technology Board, 2101 Constitution Avenue,
Washington, D.C. 20418.
If you'd like to see this book, you're welcome to drop by.
∂20-Sep-88 1616 DELAGI@SUMEX-AIM.Stanford.EDU [sprite@spur.Berkeley.EDU (Sprite OS on SPUR): Hello World]
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Sep 88 16:16:29 PDT
Date: Tue, 20 Sep 88 14:25:54 PDT
From: Bruce A. Delagi <DELAGI@SUMEX-AIM.Stanford.EDU>
Subject: [sprite@spur.Berkeley.EDU (Sprite OS on SPUR): Hello World]
To: aap@SUMEX-AIM.Stanford.EDU
Message-ID: <12432151147.24.DELAGI@SUMEX-AIM.Stanford.EDU>
Return-Path: <sprite@spur.Berkeley.EDU>
Received: from ernie.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Mon, 19 Sep 88 17:41:49 PDT
Received: from spur.Berkeley.EDU by ernie.Berkeley.EDU (5.59/1.29)
id AA04278; Mon, 19 Sep 88 17:14:05 PDT
Received: by spur.Berkeley.EDU (5.59/1.25)
id AA468781; Mon, 19 Sep 88 17:18:27 PDT
Date: Mon, 19 Sep 88 17:18:27 PDT
From: sprite@spur.Berkeley.EDU (Sprite OS on SPUR)
Message-Id: <8809200018.AA468781@spur.Berkeley.EDU>
To: world@ernie.Berkeley.EDU
Subject: Hello World
Hello World!
The purpose of this message is to officially announce that the SPUR
computer and the Sprite operating system are running well enough to
support a variety of user processes. For example, this message was
sent from SPUR using the the sendmail program. The SPUR hardware and
software were designed from scratch by the students, staff, and
faculty of the University of California at Berkeley. The system is
currently running in the lab, and has been up since September 15.
SPUR stands for Symbolic Processing Using RISCs. Each SPUR processor
board contains a 120,000 transistor custom CMOS 32-bit RISC CPU with 8
bits of tag support for Lisp and a 60,000 transistor custom CMOS
cache controller chip with invalidation-based snooping plus
off-the-shelf parts for the 128KB cache and memory interface.
SPUR workstations can contain up to twelve processors,
although our current prototype is running as a uniprocessor.
Sprite is a network operating system with a UNIX-like kernel call
interface but a completely new kernel that provides a high-performance
network file system and process migration. The SPUR project spans from
custom VLSI chips through boards, operating systems, compilers, and
multiprocessor applications. This project was funded primarily by
DARPA/ISTO, with additional support from the National Science Foundation
and chips and PC boards fabricated by the MOSIS implementation service
of ISI. A number of corporate sponsors have contributed equipment, money,
time, and advice.
We still have more we hope to do:
Get Common Lisp running on a uniprocessor SPUR;
Put our custom Floating Point chip on the board (it just arrived);
Debug the multiprocessor support on the SPUR board;
Debug the multiprocessor support in Sprite.
We expect to reach these milestones over the next several months,
but for now we are now going to our local brewery to celebrate!
Dave Patterson, P.I.
Computer Science Division / EECS
University of California at Berkeley
P.S. Email replies may be sent to spur@ginger.Berkeley.EDU
-------
∂21-Sep-88 1332 TAJNAI@Score.Stanford.EDU Sunrise Club, October 4th, 7:30 a.m.
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Sep 88 13:32:39 PDT
Return-Path: <NA.PHL@Forsythe.Stanford.EDU>
Received: from forsythe.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 21 Sep 88 13:02:10-PDT
Date: Wed, 21 Sep 88 13:02:35 PDT
To: tajnai@score
From: "Portia Leet" <NA.PHL@Forsythe.Stanford.EDU>
Subject: Sunrise Club, October 4th, 7:30 a.m.
ReSent-Date: Wed 21 Sep 88 13:14:44-PDT
ReSent-From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
ReSent-To: faculty@Score.Stanford.EDU
ReSent-Message-ID: <12432400336.19.TAJNAI@Score.Stanford.EDU>
TO ALL CS AND EE FACULTY:
Richard Pantell will be speaking at the next Sunrise Club
meeting on Tuesday, October 4th. His topic will be "Free
Electron Lasers."
We will meet, as usual, at 7:30 a.m. in the Oak Lounge West
at Tressider Union. (Breakfast will be served).
PLEASE RSVP to:
Bonnie Hiller, Hiller@score if you are in computer science
OR
Socky Gallevo at Socky@sierra if you are in electrical engineering.
Thanks and hope to see you there.
Portia Leet
To: TAJNAI@SCORE, SOCKY@SIERRA
cc: NA.PHL
∂22-Sep-88 0754 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu STOC 88 Proceedings
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Sep 88 07:54:22 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA00935; Thu, 22 Sep 88 07:52:50 PDT
Message-Id: <8809221452.AA00935@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 22 Sep 88 07:53:47 PDT
Received: by BYUADMIN (Mailer X1.25) id 8572; Thu, 22 Sep 88 08:51:49 MDT
Date: Thu, 22 Sep 88 09:47:51 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Uri N. Peled 312-413-2156" <U32799%UICVM.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Uri N. Peled 312-413-2156" <U32799%UICVM.BITNET@forsythe.stanford.edu>
Subject: STOC 88 Proceedings
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
A friend of mine has have one set of proceedings of STOC 88, which he
will part from for $39 and pay for postage too. Please send a note to
Uri Peled, U32799@UICVM on BITNET.
∂22-Sep-88 0759 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Need Turing pictures
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Sep 88 07:59:30 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA01011; Thu, 22 Sep 88 07:57:55 PDT
Message-Id: <8809221457.AA01011@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 22 Sep 88 07:58:50 PDT
Received: by BYUADMIN (Mailer X1.25) id 8667; Thu, 22 Sep 88 08:56:46 MDT
Date: Thu, 22 Sep 88 09:50:42 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Eugene Luks <luks%FOG.CS.UOREGON.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Eugene Luks <luks%FOG.CS.UOREGON.EDU@Forsythe.Stanford.EDU>
Subject: Need Turing pictures
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Two gargoyles are in the plans for our new computer science building
and, as our department was allowed to choose the themes, we have
requested that these display the visages of John von Neumann and
Alan Turing, respectively. Since the artist (Wayne Chabre) needs to
work from photos, he asked that we provide an assortment of snapshots
showing various views of the individuals.
Despite an initial warning from Paul Halmos that Johnny was actually
quite camera shy, we did find an ample photographic record of von Neumann.
That gargoyle is now complete (quite handsome and whimsically demonic).
However, we have been less successful in finding pictures of Turing.
At the moment we have little more than those shown in Andrew Hodges'
book (Alan Turing - The Enigma) which includes an oft-reproduced 3/4
portrait. Chabre would especially like to see a good profile and some
clear shots that show the subject doing something (other than posing for
a picture).
Does anyone know of a source for Turing images? Better still, does
anyone have some photographs that they would allow us to reproduce?
Thanks for any assistance.
Gene Luks
Computer and Information Science
University of Oregon
Eugene, OR 97403
luks@cs.uoregon.edu
∂22-Sep-88 0813 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu FOCS follies
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Sep 88 08:12:55 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA01355; Thu, 22 Sep 88 08:11:24 PDT
Message-Id: <8809221511.AA01355@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 22 Sep 88 08:12:18 PDT
Received: by BYUADMIN (Mailer X1.25) id 9074; Thu, 22 Sep 88 09:09:55 MDT
Date: Thu, 22 Sep 88 09:54:17 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Joe Kilian <joek%THEORY.LCS.MIT.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Joe Kilian <joek%THEORY.LCS.MIT.EDU@Forsythe.Stanford.EDU>
Subject: FOCS follies
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
CALL FOR SUBMISSIONS
FOCS Follies '88
Those of you attending this year's FOCS conference are probably facing
a serious quandry: Which of White Plain's wild nighttime activities
to indulge in? The possibilities seem endless. For instance, you can
(1) Read your FOCS proceedings.
(2) Try to reduce SAT to linear programming.
(3) Determine how many conflicting definitions of zero-knowledge
were used during the crypto session.
(4) Tear apart your room in search of the overheads for your talk
tomorrow.
(5) Wonder how MIT's Lab for Computer Science Silver Anniversary
bash is going while you're away.
(6) Reread your old STOC proceedings.
(7) Frantically redraw the overheads you've just realize are safely
locked up in your office.
(8) Aimlessly stare out your hotel window and count the cars driving by.
(9) Fantasize about having FOCS at Puerto Rico next time.
OR...
(10) AMUSE AND IMPRESS FRIENDS, COLLEAGUES, AND NSA OPERATIVES BY
PERFORMING A SKIT FOR THIS YEAR'S FOCS FOLLIES!!!!!!!
What are the FOCS follies? Well, actually, I've never seen one
myself. But Alok Aggarwal tells me they consist of a few skits,
talks, or other miscellaneous activities at the start of the business
meeting. Unlike the presentations given during the rest of the
business meeting, the follies presentations are intentionally
ludicrous. Examples from the past include the singing of IBM
corporate songs, the acting out of famous algorithms, and talks on how
to build a computer science department. I guess you had to be there.
How can you get involved? If you would like to help out with a skit, song,
contest, or any other presentation, just send me e-mail at
joek@theory.lcs.mit.edu
If you have some half-baked ideas for skits or contests, or if you're
interested but want to talk more, please also send me mail so I can
get back to you.
If you don't have access to the right networks, you can send US mail to
FOCS Follies '88
c/o Joe Kilian
MIT Lab for Computer Science
Room 330, 545 Tech Square
Cambridge, MA 02139
If all else fails, you can call me at (617)253-6259.
To further sweeten the pot, Alok says we have some limited funds for
props, prizes, and whatever graft we can sneak by him. If your idea
requires some money, please contact me as soon as possible, so I can
get some idea of how to divvy things up, and clear it all with Alok.
One final word of inducement: At this year's FOCS conference, you will
be subjected to a barrage of papers which represent MIT's idea of
theoretical computer science. If not enough outside people show any
interest in the FOCS follies, you will also be subjected to a barrage
of presentations which represent MIT's idea of humor. Think about
that long and hard. I'll be waiting to hear from you.
∂22-Sep-88 1118 emma@csli.Stanford.EDU CSLI Calendar, September 22, 4:1
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Sep 88 11:18:35 PDT
Received: by csli.Stanford.EDU (4.0/4.7); Thu, 22 Sep 88 10:16:34 PDT
Date: Thu, 22 Sep 88 10:16:34 PDT
From: emma@csli.Stanford.EDU (Emma Pease)
To: friends@csli.Stanford.EDU
Subject: CSLI Calendar, September 22, 4:1
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
22 September 1988 Stanford Vol. 4, No. 1
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR NEXT THURSDAY, 29 September 1988
12 noon TINLecture
Cordura Hall Stage-level and Individual-level Predicates
Conference Room by Angelica Kratzer
UMass Linguistics Department
Abstract in next week's Calendar
2:15 p.m. CSLI Seminar
Cordura Hall First meeting
Conference Room Ivan Sag, Herb Clark, and Jerry Hobbs
(sag@csli.stanford.edu)
See below
3:45 p.m. Tea
Ventura Hall
4:00 p.m. STASS Seminar
Cordura Hall Counterfactual Reasoning
Conference Room UMass Linguistics Department
--------------
ANNOUNCEMENT
CSLI Thursdays 1988-89
in the
Cordura Hall Conference Room
This year the traditional TINLunch time (12:00-1:15) will be used for
three different types of activities---TINLunches, TINLectures, and
TINLabs---in approximately equal numbers and on an approximately
rotating schedule. TINLunches will follow the familiar format;
TINLectures will feature talks by outside speakers; and TINLabs will
provide an introduction to research at CSLI. The TINLineup begins on
29 September with a TINLecture by Angelica Kratzer from the University
of Mass; her talk will be on "Stage-level and Individual-level
Predicates." On 6 October Martin Kay will lead a TINLab on "What is
Unification Grammar?" Watch the CSLI Calendar for coming attractions.
CSLI SEMINAR (2:15-3:45) will focus each quarter on a particular
issue or problem. CSLI researchers and others will discuss the
bearing their work has on the issue.
The fall quarter seminar is being organized by Ivan Sag, Herb
Clark, and Jerry Hobbs; the issue is: The Resolution Problem for
Natural-Language Processing. How can communication proceed in light
of the fact that interpretation is radically underdetermined by
linguistic meaning?
Languages exhibit massive ambiguity:
I forgot how good beer tastes. [Structural ambiguity]
The pen is empty. [Lexical ambiguity]
Dukakis agrees to only three debates. [Scope ambiguity]
I saw her duck. [Lexical and structural ambiguity]
Kim likes Sandy more than Lou. [Ellipsis ambiguity]
And massive parametricity (expressions whose interpretation relies in
part on contextually fixed parameters):
He is crazy. (Who's he?)
John is in charge. (John who? In charge of what?)
She ran home afterwards. (After what?)
The nail is in the bowl. (Which nail? Nailed into the bowl, or just
inside of it?)
She cut the lawn/hair/cocaine/record. (What kind of cutting?)
John's book. (The book he owns?/wrote?/edited?)
The Resolution Problem for natural language is the question of how
diverse kinds of knowledge (e.g., knowledge of local domains, context
of utterance, the plans and goals of interlocutors, and knowledge of
the world at large) interact with linguistic knowledge to make
communication possible, even efficient. In this seminar, which will
include presentations by the instructors, by Michael Tanenhaus
(University of Rochester), and by David Rumelhart, we attempt to
clarify the nature of the Resolution Problem and to consider a
diversity of approaches toward a solution.
This course is listed as Linguistics 232, Psychology 229, and
Computer Science 379 and may be taken for 1-3 units by registered
Stanford students.
TEA will be served in the Ventura Lounge following these events at
3:45.
--------------
STASS SEMINAR
Counterfactual Reasoning
Angelica Kratzer, UMass Linguistics Department
The STASS seminar meets every other Thursday, 4:00-5:30, in the
Cordura Conference Room. Everybody is welcome.
∂22-Sep-88 1139 helen@russell.Stanford.EDU ssp descriptions
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Sep 88 11:39:25 PDT
Received: by russell.Stanford.EDU (4.0/4.7); Thu, 22 Sep 88 11:38:52 PDT
Date: Thu 22 Sep 88 11:38:51-PDT
From: Helen Nissenbaum <HELEN@CSLI.Stanford.EDU>
Subject: ssp descriptions
To: ssp-faculty@russell.Stanford.EDU
Message-Id: <590956731.0.HELEN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Here is the most recent version of our SSP faculty descriptions. We have
tried to keep a uniform format organizing information under three headings:
research interests, selected publications, and projects.
Please take a few minutes to look at yours and compare it to those of others.
Its not absolutely necessary to have each of the subheadings filled -- we merely
wanted to show what they are. In the final version, if there's nothing under
a subheading we'll simply erase it.
Speak now or forever hold your peace!
{\bf Jon Barwise}, Director, Department of Philosophy. Research
interests: logic, semantics of natural language, information theory.
Selected publications: {\it The Liar}, with John Etchemendy, and {\it
Situations and Attitudes}, with John Perry. Editor of the {\it
Handbook of Mathematical Logic.} Projects: STASS Projects, CSLI
{\bf Joan Bresnan} Department of Linguistics. Research interests:
grammatical theory, lexical structure, morphology-syntax-discourse
interactions, structure of Bantu, English syntax, computational and
psycholinguistics. Selected publications:
Projects:
{\bf Herbert H. Clark} Department of Psychology. Reasearch interests:
psycholinguistics, study of cognitive and social processes in language
use, word meaning and speaker meaning, discourse. Special interest in
speaking, understanding, and memory in conversation.
Selected publications: {\it Psychology and Language} (with E.V. Clark);
``Language users and language use'' (in {\it Handbook of Social Psychology);
``Definite reference and mutual knowledge'' (with C.R. Marshall); and
``Referring as a collaborative process'' (with D. Wilkes-Gibbs).
Projects:
{\bf Phil Cohen} Program Director, Natural Language, AI Center,
SRI International, Consulting Associate Professor. Research
Interests: Artificial Intelligence,
natural language processing, speech act theory,human-computer interfaces,
applications to factory automation. Selected publications:
``Intention as Choice with Commitment'' (with Hector Levesque),
``Rational Interaction as the Basis for communication'' (with Hector Levesque).
Projects:
{\bf John Etchemendy} Department of Philosophy. Research interests:
logic, semantics of natural language, philosophy of mind. Selected
publications: ``The Doctrine of Logic as Form;'' {\it The Liar}, with
Jon Barwise; ``Models, Semantics and Logical Truth;'' {\it The Concept
of Logical Consequence}. Projects:
{\bf Solomon Feferman} Professor of Mathematics and Philosophy, Chairman
Dept. of Mathematics. Research interests: logic (especially proof theory,
constructive and explicit mathematics, computability theory), foundations
of mathematics, and history of modern logic. Selected publications:
(\it Model-theoretic logics), co-edited with Jon Barwise,
{\it Kurt Godel. Collected Works, Vol. I}, as editor-in-chief, and
{\it Iterated inductive definitions and subsystems of analysis}, with
W.Buchholz et al. Editor: Perspectives in Mathematical Logic series.
Projects:
{\bf James Greeno} School of Education. Research interests: ways that
formal symbolic systems, such as high-school algebra, can be
understood meaningfully. Selected Publications: ``On the nature of
competence: Principles for understanding in domains'' (with R.
Gelman). ``Situations, mental models, and generative knowledge'', ``A
perspective on thinking''. Projects: studying high-school students'
implicit understanding of concepts of variable and function. Study of
children's understanding of terms about numbers, sets, and other
mathematical concepts (working with Susan Stucky). Ongoing project in
theory of problem solving. Planning a project with Jon Barwise and
John Etchemendy to study learning process in the computer-based
instructional program Tarski's World.
{\bf Joe Halpern}, Manager, Departments of Mathematics and Computer Science,
IBM Almaden Research Center, Consulting Associate Professor. Research
Interests: reasoning about knowledge, distributed systems, modal logics,
logics of programs, cryptographic protocols.
Program Chairman: First Conference on Theoretical Aspects of Reasoning
About Knowledge, 1986, and 6th ACM Symposium on Principles of
Distributed Computing, 1986. Selected publications:
Projects:
Editor of journal {\it Information and Computation}.
{\bf Pat Hayes} Xerox PARC, Consulting Professor.
Research interests: Mechanical reasoning and the representation of
everyday knowledge especially knowledge about the physcial world.
Selected publications:
Projects:
{\bf David Israel} SRI AI Center, Consulting Professor.
Research Interests: Semantics of Natural Language; Mind and Action.
Selected publications: ``The Role of Propositional Objects of Belief''
in {\it Action,
What is Information?} (with John Perry), ``Resource-Bounded Practical
Reasoning'' (with Michael Bratman and Martha Pollack).
Projects:
{\bf Roy Jones} Acting Assistant Chairman for Education, Department of
Computer Science. Research interests: Artificial Intelligence, social issues.
Projects:
{\bf Ron Kaplan} Xerox PARC, Consulting Professor.
Research Interests:
Selected Publications:
Projects:
{\bf Lauri Karttunen} Xerox PARC, Consulting Professor.
Research Interests: computational linguistics,
especially development of systems for morphological analysis and
unification-based grammars;
semantics, the syntax of Finnish; and categorial grammar.
Selected publications:
Projects:
{\bf Martin Kay} Department of Linguistics.
Research Interests:
Selected publications:
Projects:
{\bf John McCarthy} Department of Computer Science. Research interests:
formalizing common sense knowledge and reasoning using mathematical
logical languages. Selected publications:
``First Order Theories of Individual Concepts and Propositions'',
in Michie, Donald (ed.) {\it Machine Intelligence},
``Ascribing Mental Qualities to Machines'' in {\it Philosophical Perspectives
in Artificial Intelligence}, ``Some Expert Systems Need Common Sense'',
in {\it Computer Culture: The Scientific, Intellectual and Social Impact
of the Computer}. Projects:
{\bf Nils Nilsson} Chairman, Department of Computer Science. Research
interests: communicating, distributed AI systems, robots that
cooperate to perform tasks. Past president of AAAI, he is interested
in effects of AI on society. Selected publications:
Projects:
{\bf Helen Nissenbaum} Symbolic Systems Program, Program Coordinator.
Research interests: emotion, philosophical foundations, ethics in the use of
computers. Selected publications: {\bf Emotion and Focus}
{\bf Misha Pavel} Department of Psychology. Research Interests:
perceptual and cognitive processes applied to human machine
interaction; computer-user psychology, computer assited instruction.
Selected publications:
Projects: study of eye movements, knowledge representation, computer
graphics, image processing and mathematical modeling.
{\bf Ray Perrault} AI Center, SRI International, Consulting Professor.
Research Interests: relation between language, mental
states, and action; semantic accounts of nondeclarative sentences and
extended discourse; computational models of agents engaged in
extended disscourse. Selected publications:
Projects:
{\bf John Perry} Department of Philosophy. Teaches courses in
philosophy of mind, the philosophy of language, metaphysics and the
history of philosophy. Research interests:
intentionality, propositional attitudes and the self. Selected
publications:
{\it A Dialogue on Personal Identity and Immortality}, {\it Situations and
Attitudes} (with Jon Barwise) and "What is Information" (with David
Israel). Projects:
{\bf Stanley Peters} Department of Linguistics, Director of CSLI.
Research interests:
semantics and syntax of natural language, mathematical theories of
language, computational linguistics. Selected publications: {\it
Introduction to Montague Semantics}, with David Dowty and Robert Wall,
``On some formal properties of metarules,'' with Hans Uszkoreit, in
{\it Linguistics and Philosophy} (1986).
{\bf Stuart Reges} Department of Computer Science CSD. Chief Reader,
AP exam in CS.
Interests: computer science education Selected publications: {\it Building
Pascal Programs}. Projects: spending most of '88-89 working on
Computer Science
textbooks and a book on object-oriented programming that will be of
interest to people writing software for the NeXT machine.
{\bf Paul S. Rosenbloom}, Department of Computer Science (on leave). Research
interests: cognitive architecture, machine learning. Selected publications:
{\it Soar: An architecture for general intelligence} and {\it Chunking
in Soar: The anatomy of a general learning mechanism}, both with John
E. Laird and Allen Newell.
{\bf Stan Rosenschein} Telios, Consulting Professor. Research interests:
formal semantic models of information, analysis and design of software
for robots and other intelligent, embedded systems; the use of logic
of knowledge as a tool in designing real-time AI systems.
Selected publications:
Projects:
{\bf David Rumelhart} Department of Psychology. Research interests: computer
modeling of learning, visual perception, language understanding, and
memory. Selected publications:
Projects:
{\bf Ivan Sag} Department of Linguistics. Research
interests: grammatical theory, semantics of natural language,
natural language processing, English syntax.
Selected publications: {\it Information-Based Syntax and Semantics},
with Carl Pollard; ``Toward a Theory of Anaphoric Processing'', with
Jorge Hankamer. Editor: {\it Elements of Discourse Understanding}, with
Aravind Joshi and Bonnie Webber. Projects:
{\bf Yoav Shoham}, Department of Computer Science. Research interests:
reasoning about the commonsense world especially temporal reasoning
and causation; spatial reasoning in modeling simple mechanical
devices; logic, Prolog. Selected publications:
Projects:
{\bf Brian Smith} Xerox PARC, Consulting Professor.
Research interests: foundations of artificial intelligence and computation,
philosophy of computation and mind, social and ethical aspects of
computation. Selected publications:
Projects:
{\bf Barbara Tversky}, Department of Psychology. Research interests:
categorization, pictorial memory and pictorial cognition.
Selected publications:
Projects:
{\bf Thomas Wasow} Departments of Linguistics and Philosophy, Dean of
Undergraduate Studies.
Research interests: grammatical theory, computational linguistics,
cognitive science. Selected publications: ``Transformations and the
Lexicon'', and {\it Anaphora in Generative Grammar}. Editor of {\it
Formal Syntax}, with Peter Culicover and Adrian Akmajian. Projects:
{\bf Terry Winograd}, Department of Computer Science.
Research interests: Meaning and interpretation (hermeneutics),
linguistic basis for computer system design, foundations of cognitive
science, human-computer interaction. Selected publications: {\it
Language as a Cognitive Process}, {\it Understanding Computers and
Cognition: A New Foundation for Design}, with Fernando Flores.
Projects:
{\bf Annie Zaenen} Xerox-Parc, Consulting Professor. Research interests:
syntax and semantics of natural language;interface between syntax and
the lexicon. Selected Publications:
Projects:
-------
∂22-Sep-88 1529 TAJNAI@Score.Stanford.EDU Next debut
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Sep 88 15:29:09 PDT
Date: Thu 22 Sep 88 15:27:03-PDT
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Next debut
To: faculty@Score.Stanford.EDU, jwilson@Score.Stanford.EDU,
reges@Score.Stanford.EDU, reuling@Score.Stanford.EDU
cc: rlm@Score.Stanford.EDU
Message-ID: <12432686567.47.TAJNAI@Score.Stanford.EDU>
Robert Miller, the new Forum staff member, is a writer. He has been
asked by Bob Fenster, Editor of The Tab (a Palo Alto paper) to cover
the debut of the Next computer on Oct. 12 at Davies Hall.
We have not been able to get a ticket for him. If anyone has a spare one
or can pull one out of the hat, I would be most grateful. We did try
calling Dan'l Lewin, but he is out. His secretary referred Robert to
the PR firm, who said, "sorry -- all gone."
Carolyn
-------
∂22-Sep-88 1617 ullman@polya.Stanford.EDU postdoc opportunity
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Sep 88 16:17:44 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA18803; Thu, 22 Sep 88 16:15:59 PDT
Date: Thu, 22 Sep 88 16:15:59 PDT
From: Jeffrey D. Ullman <ullman@polya.Stanford.EDU>
Message-Id: <8809222315.AA18803@polya.Stanford.EDU>
To: aflb-local@polya.Stanford.EDU
Subject: postdoc opportunity
The following was mailed me by Joan Feigenbaum.
**************************************
Return-Path: <jf@research.att.com>
Received: from ATT.ARPA by polya.Stanford.EDU (5.59/25-eef) id AA02022; Mon, 19 Sep 88 13:00:56 PDT
Message-Id: <8809192000.AA02022@polya.Stanford.EDU>
From: jf@research.att.com
Date: Mon, 19 Sep 88 15:54:15 EDT
To: ullman@polya.stanford.edu
Are there students (not necessarily your own) in your department
who would be interested in this?
-------------------------------------------------------------
The Computing Science Research Center at AT&T Bell Laboratories
has a position for a Postdoctoral Fellow in Theoretical Computer
Science. This is a one-year position, beginning in September
of 1989. Applicants should be graduate students who will
receive PhD's in the spring of 1989. Desired areas of
interest include, but are not limited to, the following:
Algorithms and Data Structures
Computability and Structural Complexity Theory
Computational Geometry
Cryptography and Network Security
Graph Theory and Graph Algorithms
The Theory of Parallel and Distributed Computation
Semantics of Programming Languages
-------------------------------------------------------------
If so, please tell them to get in touch with me. I will be at
FOCS next month and can talk to people there. If your students
won't be at FOCS (or if they and I don't catch up with each other
there), then you can have them get in touch with me here; my
email address is jf@research.att.com and my number is 201-582-6910.
If you want to talk to me before telling someone to apply, please
feel free.
In any case, I need a resume and a ONE-PAGE thesis summary from
every applicant by DECEMBER 1, 1988. The address is:
Joan Feigenbaum
AT&T Bell Labs, Room 2C473
600 Mountain Avenue
Murray Hill, NJ 07974
USA
Regards,
Joan
∂22-Sep-88 1752 bresnan@russell.Stanford.EDU Re: ssp descriptions
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Sep 88 17:49:02 PDT
Received: from localhost by russell.Stanford.EDU (4.0/4.7); Thu, 22 Sep 88 17:49:00 PDT
To: Helen Nissenbaum <HELEN@CSLI.Stanford.EDU>
Cc: ssp-faculty@russell.Stanford.EDU
Subject: Re: ssp descriptions
In-Reply-To: Your message of Thu, 22 Sep 88 11:38:51 PDT.
<590956731.0.HELEN@CSLI.Stanford.EDU>
Date: Thu, 22 Sep 88 17:48:58 PDT
From: bresnan@russell.Stanford.EDU
{\bf Joan Bresnan} Department of Linguistics. Research interests:
grammatical theory, lexical structure, morphology-syntax-discourse
interactions, structure of Bantu, English syntax, computational and
psycholinguistics. Selected publications: {\it The Mental
Representation of Grammatical Relations,} ``Topic, Pronoun, and
Agreement in Chichewa'' (with Sam A. Mchombo).
Projects: GTDS Project, CSLI
∂23-Sep-88 0740 @Score.Stanford.EDU:tom@polya.Stanford.EDU IBM RT's/6152's demo systems
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Sep 88 07:35:09 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 23 Sep 88 07:32:01-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA06250; Fri, 23 Sep 88 07:32:35 PDT
Date: Fri, 23 Sep 88 07:32:35 PDT
From: Tom Dienstbier <tom@polya.Stanford.EDU>
Message-Id: <8809231432.AA06250@polya.Stanford.EDU>
To: combuyn@sail, faculty@score, su-computers@polya.Stanford.EDU
Subject: IBM RT's/6152's demo systems
Folks, this is to let you know that IBM is offering an assortment of
workstations to the University at very good prices. The following
equipment is located in Margaret Jacks Hall, room 030, Computer Science
Department, for your viewing pleasure. These systems have been mentioned on the
COMBUYN mailing list to mostly departmental purchasing types.
1. RT system Mod. 125
16MB Ram, 300MB Disk, Ethernet Card, Advanced Floating Point Adapter,
1024 X 1024 19" Color Display, UNIX 4.3OS including Source,NFS,X11.
2. RT System Mod. 6152
8MB Ram, 70MB Disk, Ethernet Card, 1024 X 768 16" Color Display,
UNIX 4.3, DOS
Please feel free to come by and look/use these demo systems.
I have price sheets in my office. We are not authorized to post the prices
on the some of the BBoards.
For additional information call Karen M. Iburg 408-288-4059 or
Kalon Goodrich 408-288-4962
Tom Dienstbier
CSDCF
MJH rm.040
3-1767
∂23-Sep-88 0836 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Survey of Bin Packing Algorithms
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Sep 88 08:36:05 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA07422; Fri, 23 Sep 88 08:34:27 PDT
Message-Id: <8809231534.AA07422@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 23 Sep 88 08:35:23 PDT
Received: by BYUADMIN (Mailer X1.25) id 5550; Fri, 23 Sep 88 09:33:22 MDT
Date: Fri, 23 Sep 88 10:28:25 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Philip Matthews <mcvax!enea!dkuug!daimi!matthews@UUNET.UU.NET>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Philip Matthews <mcvax!enea!dkuug!daimi!matthews@UUNET.UU.NET>
Subject: Survey of Bin Packing Algorithms
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
>Can anyone please provide me with a small, recent list of references
>on the 2 dimensional bin packing problem and solutions?
You might try
Approximation Algorithms for Bin-Packing -- An Updated Survey
by E.G. Coffman, M.R. Garey, D.S. Johnson
(I believe this has not yet been published, but you can get
a copy by sending E-mail to D.S. Johnson (dsj@btl.csnet))
This covers more than you want, but it does survey 2-D problems
and algorithms.
∂23-Sep-88 0839 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu SIGACT News
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Sep 88 08:38:54 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA07518; Fri, 23 Sep 88 08:37:18 PDT
Message-Id: <8809231537.AA07518@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 23 Sep 88 08:38:14 PDT
Received: by BYUADMIN (Mailer X1.25) id 5644; Fri, 23 Sep 88 09:36:10 MDT
Date: Fri, 23 Sep 88 10:31:34 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Mike Langston <langston%cs1.wsu.edu@RELAY.CS.NET>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Mike Langston <langston%cs1.wsu.edu@RELAY.CS.NET>
Subject: SIGACT News
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
TheoryNet subscribers and SIGACT members obviously share a lot of common
interests. Nevertheless, I see many interesting items posted to TheoryNet
that are not submitted for publication in SIGACT News. Examples include
conference announcements, conference programs, open problems, and so on.
If you have an item of interest to the theory community (as broadly defined),
I'd like to remind you that SIGACT News is available and reaches an audience
of well over 2000 members. Feel free to contact me if you have questions
about the News.
Mike Langston
SIGACT News Editor
email: langston@cs1.wsu.edu
snail mail: Computer Science Dept, Washington State Univ, Pullman, WA 99164-1210
phone: (509) 335-6486
∂23-Sep-88 0902 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Sep 88 09:02:12 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA07987; Fri, 23 Sep 88 09:00:29 PDT
Message-Id: <8809231600.AA07987@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 23 Sep 88 09:01:22 PDT
Received: by BYUADMIN (Mailer X1.25) id 5979; Fri, 23 Sep 88 09:59:16 MDT
Date: Fri, 23 Sep 88 10:33:56 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
========================================================================
Received: from cs1.wsu.edu by IBM.COM on 09/19/88 at 23:25:14 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa11733; 20 Sep 88 2:25 EDT
Received: from wsu.edu by RELAY.CS.NET id aj17380; 20 Sep 88 2:11 EDT
Return-Path: <langston@cs1.wsu.edu>
Received: by cs1.wsu.edu (4.12/)
id AA02196; Mon, 19 Sep 88 10:38:19 pdt
Date: Mon, 19 Sep 88 10:38:19 pdt
From: Mike Langston <langston%cs1.wsu.edu@RELAY.CS.NET>
Full-Name: Mike Langston
To: TheoryNet@IBM.COM
Subject: SIGACT News
TheoryNet subscribers and SIGACT members obviously share a lot of common
interests. Nevertheless, I see many interesting items posted to TheoryNet
that are not submitted for publication in SIGACT News. Examples include
conference announcements, conference programs, open problems, and so on.
If you have an item of interest to the theory community (as broadly defined),
I'd like to remind you that SIGACT News is available and reaches an audience
of well over 2000 members. Feel free to contact me if you have questions
about the News.
Mike Langston
SIGACT News Editor
email: langston@cs1.wsu.edu
snail mail: Computer Science Dept, Washington State Univ, Pullman, WA 99164-1210
phone: (509) 335-6486
∂23-Sep-88 1053 X3J13-mailer compiler cleanup issue status
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:53:25 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28898; Fri, 23 Sep 88 11:52:03 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02492; Fri, 23 Sep 88 11:52:00 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231752.AA02492@defun.utah.edu>
Date: Fri, 23 Sep 88 11:51:59 MDT
Subject: compiler cleanup issue status
To: x3j13@sail.stanford.edu
X3J13 Compiler Cleanup Status as of 23 Sep 1988:
================================================
Old issues (distributed for comments at the June meeting), ready to be
voted upon:
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
What are the compile-time side-effects of the various defining
macros?
EVAL-WHEN-NON-TOP-LEVEL
What does EVAL-WHEN mean when it does not appear as a top-level
form?
DEFINING-MACROS-NON-TOP-LEVEL
Can defining macros such as DEFUN appear in non-top-level
locations?
This issue provoked the only comments that were received since
the last meeting:
* The wording of section 4 was garbled.
This has been fixed in the latest version of the proposal.
* Many implementations do not allow a lexical environment to be
shared between compiled and interpreted functions.
A new issue, COMPILE-ARGUMENT-PROBLEMS, has been written up
to deal with this problem.
* Forms within a COMPILER-LET and the expansion of a top-level
macro should also be considered top-level.
This has been fixed.
New issues that are ready to be voted upon:
COMPILE-ARGUMENT-PROBLEMS
What functions can be compiled with COMPILE?
COMPILE-FILE-PACKAGE
COMPILE-FILE should rebind *PACKAGE*.
OPTIMIZE-DEBUG-INFO
What OPTIMIZE quality controls debuggability of compiled code?
PROCLAIM-INLINE-WHERE
INLINE proclamations should be placed before the corresponding
DEFUN.
Issues in draft form (comments requested):
COMPILE-ENVIRONMENT-CONSISTENCY
What things can the compiler safely "wire in" to code being
compiled?
PROCLAIM-ETC-IN-COMPILE-FILE
Add PROCLAIM, REQUIRE to list of N random package functions that
COMPILE-FILE must eval at compile time.
Issues in progress (no proposals ready yet):
LOAD-TIME-EVAL
What does #, mean? Where can it appear?
COMPILED-CONSTANTS
Are quoted constants in compiled code read-only? Must the compiler
handle circular constants? Preserve nonprintable aspects of constant
data?
-------
∂23-Sep-88 1054 X3J13-mailer issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:54:04 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28914; Fri, 23 Sep 88 11:52:40 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02497; Fri, 23 Sep 88 11:52:36 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231752.AA02497@defun.utah.edu>
Date: Fri, 23 Sep 88 11:52:35 MDT
Subject: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
To: x3j13@sail.stanford.edu
Issue: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
References: CLtL pages 66-70, 143
Category: CLARIFICATION
Edit history: V1, 07 Oct 1987 Sandra Loosemore
V2, 15 Oct 1987 Sandra Loosemore
V3, 15 Jan 1988 Sandra Loosemore
V4, 06 May 1988 Sandra Loosemore
V5, 20 May 1988 Sandra Loosemore
V6, 09 Jun 1988 Sandra Loosemore
Problem Description:
Standard programming practices assume that, when calls to defining
macros such as DEFMACRO and DEFVAR are processed by COMPILE-FILE,
certain side-effects occur that affect how subsequent forms in the
file are compiled. However, these side-effects are not mentioned in
CLtL, except for a passing mention that macro definitions must be
``seen'' by the compiler before it can compile calls to those macros
correctly. In order to write portable programs, users must know
exactly which defining macros have compile-time side-effects and what
those side-effects are.
Inter-file compilation dependencies are distinct from, and not
addressed by, this issue.
Proposal: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
(1) Clarify that defining macros such as DEFMACRO or DEFVAR, appearing
within a file being processed by COMPILE-FILE, normally have
compile-time side effects which affect how subsequent forms in the
same file are compiled. A convenient model for explaining how these
side effects happen is that the defining macro expands into one or
more EVAL-WHEN forms, and that the calls which cause the compile-time
side effects to happen appear in the body of an (EVAL-WHEN (COMPILE)
...) form. This is also the recommended implementation technique.
(2) The affected defining macros and their specific side effects are
as follows:
DEFTYPE: The body of a DEFTYPE form must be evaluable at compile time.
If the expansion of a DEFTYPE'd type specifier is also a valid type
specifier at compile time, then the DEFTYPE'd type specifier is also
considered to be fully defined at compile time and must be recognized
within subsequent type declarations.
DEFMACRO, DEFINE-MODIFY-MACRO: Macro definitions must be stored at compile
time, so that occurences of the macro later on in the file will be expanded
correctly. The body of the macro (but not necesarily its expansion) must
be evaluable at compile time.
DEFUN: An implementation may choose to store information about the
function for the purposes of compile-time error-checking (such as
checking the number of arguments on calls), or to enable the function
to be expanded inline. Portable code should not rely on DEFUN making
the function definition available at compile time.
DEFVAR, DEFPARAMETER: The compiler must recognize that the variables
named by these forms have been proclaimed special. The initial value
form must not be evaluated at compile time.
DEFCONSTANT: The compiler must recognize the symbol as being constant
(for example, to suppress warnings about references to the symbolic
constant as an unbound variable or to enable warnings about binding or
SETQ'ing the constant in the code being compiled). Neither evaluation
of the value-form or SETQ'ing of the symbol may occur at compile-time.
However, if the (unevaluated) value-form is CONSTANTP, the compiler is
allowed to build assumptions about the value of the constant into
programs being compiled, as described on p. 68-69 of CLtL.
DEFSETF, DEFINE-SETF-METHOD: SETF methods must be available during the
expansion of calls to SETF later on in the file. The body of
DEFINE-SETF-METHOD and the complex form of DEFSETF must be evaluable
at compile time, although the expansions need not be.
DEFSTRUCT: The structure type name must be recognized as a valid type name
in declarations, as for DEFTYPE. The structure slot accessors must be made
known to SETF. In addition, further DEFSTRUCT definitions should be able
to :INCLUDE a structure type defined earlier in the file being compiled.
The functions which DEFSTRUCT generates, and the #S reader syntax, may or
may not be available at compile time.
(3) The compile-time side effects may cause information about the
definition to be stored differently than if the defining macro had
been processed in the "normal" way (either interpretively or by loading
the compiled file).
In particular, the information stored by the defining macros at
compile time may or may not be available to the interpreter (either
during or after compilation), or during subsequent calls to COMPILE or
COMPILE-FILE. For example, the following code is nonportable because
it assumes that the compiler stores the macro definition of FOO where
it is available to the interpreter:
(defmacro foo (x) `(car ,x))
(eval-when (eval compile load)
(print (foo '(a b c))))
A portable way to do the same thing would be to include the macro definition
inside the EVAL-WHEN:
(eval-when (eval compile load)
(defmacro foo (x) `(car ,x))
(print (foo '(a b c))))
Rationale:
The proposal reflects standard programming practices. The primary
purpose of the proposal is to make an explicit statement that CL
supports the behavior that most programmers expect and many
implementations already provide.
Current Practice:
Many (probably most) Common Lisp implementations, including VaxLisp
and Lucid Lisp, are already largely in conformance.
In VaxLisp, macro definitions that occur as a side effect of compiling
a DEFMACRO form are available to the compiler (even on subsequent calls
to COMPILE or COMPILE-FILE), but are not available to the interpreter
(even within the file being compiled).
Kyoto Common Lisp is a notable offender. By default, KCL evaluates *all*
top level forms as they are compiled, which is clearly in violation of the
behavior specified on p 69-70 of CLtL. There is a flag to disable the
compile-time evaluation, but then macros such as DEFMACRO, DEFVAR, etc. do
not make their definitions available at compile-time either.
Cost to implementors:
Making the defining macros expand into EVAL-WHENs to store the required
information is a simple and recommended implementation technique. The
intent of the proposal is specifically not to require the compiler to
have special knowledge about each of these macros.
Cost to users:
Since CLtL does not specify whether and what compile-time side-effects
happen, any user code which relies on them is, strictly speaking,
nonportable. In practice, however, most programmers already expect
the behavior described in this proposal and will not find it to be
an incompatible change.
Benefits:
Adoption of the proposal will provide more definite guidelines on how to
write programs that will compile correctly under all CL implementations.
Discussion:
Reaction to an earlier version of this proposal on the CL mailing list was
overwhelmingly positive.
It has been suggested that this proposal should also include PROCLAIM.
However, since PROCLAIM is not a macro, its compile-time side effects
cannot be handled using the EVAL-WHEN mechanism. A separate proposal
seems more appropriate.
There has also been a suggestion that DEFCONSTANT should always
evaluate the value provided. The behavior specified in this proposal
makes DEFCONSTANT similar to DEFVAR and DEFPARAMETER, while allowing
the user to explicitly ask for compile-time evaluation using the #. read
macro.
Item (3) allows for significant deviations between implementations.
While there is some sentiment to the effect that the compiler should
store definitions in a manner identical to that of the interpreter,
other people believe strongly that compiler side-effects should be
completely invisible to the interpreter. The author is of the opinion
that since this is a controversial issue, further attempts to restrict
this behavior should be considered as separate proposals.
-------
∂23-Sep-88 1054 X3J13-mailer issue EVAL-WHEN-NON-TOP-LEVEL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:54:38 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28938; Fri, 23 Sep 88 11:53:11 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02502; Fri, 23 Sep 88 11:53:08 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231753.AA02502@defun.utah.edu>
Date: Fri, 23 Sep 88 11:53:07 MDT
Subject: issue EVAL-WHEN-NON-TOP-LEVEL
To: x3j13@sail.stanford.edu
Issue: EVAL-WHEN-NON-TOP-LEVEL
References: CLtL p. 69-70
Issue DEFINING-MACROS-NON-TOP-LEVEL
Category: CLARIFICATION, ENHANCEMENT
Edit History: 6-May-88, V1 by Sandra Loosemore
Problem Description:
The current description of how the compiler should handle EVAL-WHEN
only makes sense when it appears as a top-level form in the file being
compiled. Other proposals being considered by the compiler cleanup
committee require that we clarify how the compiler should process
EVAL-WHENs appearing at non-top-level, such as within LET or FUNCTION
special forms.
Proposal: EVAL-WHEN-NON-TOP-LEVEL:CLARIFY
In this proposal, we view EVAL-WHEN as a macro which expands into a
PROGN containing the body of the EVAL-WHEN when the context in which it
is expanded matches one of the situations listed, or NIL otherwise.
However, it is explicitly *not* proposed that EVAL-WHEN's status as
a special form be changed.
The EVAL situation corresponds to the normal processing of the
interpreter. If EVAL is specified, the interpreter evaluates each
form in the body of the EVAL-WHEN as an implicit PROGN, using the
current lexical environment. If the EVAL situation is not specified,
then the interpreter must return NIL as the value of the EVAL-WHEN
form, without evaluating the body.
The LOAD situation corresponds to the normal processing of the
compiler. If LOAD is specified, the compiler treats the EVAL-WHEN as
a PROGN and compiles the body in the normal way in the appropriate
lexical environment. Otherwise, the form is equivalent to specifying
a constant value of NIL. (The name LOAD is something of a misnomer,
because ``evaluation'' of the body happens not at LOAD time, but when
the EVAL-WHEN form would normally be ``evaluated''. For example, if
an EVAL-WHEN form appears in the body of a DEFUN, it is ``evaluated''
when that function is called.)
The COMPILE situation is a special case; it indicates that the
compiler itself should evaluate the body of the EVAL-WHEN form as an
implicit PROGN in the null lexical environment. During the
evaluation, if a nested EVAL-WHEN appears in the body, the interpreter
follows its usual rule of checking only whether or not the EVAL
situation is specified to decide whether or not the body of the nested
EVAL-WHEN should be processed.
If both the COMPILE and LOAD situations are specified, the compiler
first performs the evaluation for the COMPILE situation. Then, the
normal processing for the LOAD situation takes place, except that the
compile-time evaluation of nested (EVAL-WHEN (COMPILE) ...) forms in
the body is suppressed, preventing repeated evaluations of subforms.
(EVAL-WHEN (COMPILE) ...) should be used with caution in non-top-level
situations. For example, if the following appears as a top level form
in a file being compiled
(let ((x (some-hairy-computation)))
(eval-when (eval compile load) (print x)))
the variable X will be treated as special during the compile-time
evaluation, and the value printed will be its symbol-value. To
guarantee consistency between compile-time evaluation and the normal
processing, one should wrap the entire top-level form in an EVAL-WHEN,
as follows:
(eval-when (eval-compile load)
(let ((x (some-hairy-computation)))
(print x)))
Rationale:
The behavior of top-level EVAL-WHENs as specified in this proposal
remains almost identical to that specified in CLtL. The major
addition is specifying the lexical environment in which non-top-level
EVAL-WHENs are processed. It is clear that the COMPILE situation must
always be processed in the null lexical environment, since the actual
lexical environment is not available at compile time. Having the EVAL
and LOAD situations evaluate in the proper environment leads to
differing semantics, but it appears to be the behavior that most
people expect, and it is also the easiest to implement.
Suppression of COMPILE evaluations in nested EVAL-WHENs is necessary
to achieve certain desirable behaviors, such as the macro example in
section 4 of the DEFINING-MACROS-NON-TOP-LEVEL proposal.
Although viewing EVAL-WHEN as a macro is useful for purposes of
explanation, user code is likely to want to continue to treat EVAL-WHEN
as a special form. For example, a preprocessor that performs a code
walk should leave EVAL-WHENs intact, since the context in which the
preprocessor runs may not be the same as the context in which the code
it produces runs.
Current Practice:
Cost to implementors:
Probably fairly minor in most implementations.
As an implementation technique, we suggest implementing EVAL-WHEN as a
macro which uses a state variable to keep track of the current context.
A sample implementation might look something like:
(defvar *compiling-p* nil "Are we compiling or interpreting?")
(defmacro eval-when (situations &body body)
(cond
;; If the COMPILE situation applies, evaluate the body now
;; and also see if we need to do the LOAD situation too.
;; If so, shadow the definition of EVAL-WHEN to make it
;; ignore nested compile-time evaluation requests, and
;; return the body.
((and *compiling-p* (member 'compile situations))
(eval `(progn ,@body))
(if (member 'load situations)
`(macrolet ((eval-when (situations &body body)
(if (member 'load situations)
`(progn ,@body)
'nil)))
,@body)
'nil))
;; If either the EVAL or LOAD situation applies, return a PROGN.
((if *compiling-p*
(member 'load situations)
(member 'eval situations))
`(progn ,@body))
;; Otherwise no situation applies, so just return NIL.
(t
'nil)))
;;; Eval must bind *compiling-p* to NIL.
(defun eval (form)
(let ((*compiling-p* nil))
:
))
;;; Compile and Compile-file must bind *compiling-p* to a non-nil value.
(defun compile (name &optional definition)
(let ((*compiling-p* t))
:
))
(defun compile-file (input-pathname &key output-file)
(let ((*compiling-p* t))
:
))
Cost to users:
Since CLtL does not currently specify what the meaning of EVAL-WHEN
forms at non-top-level is, existing code which depends on their use is
already nonportable. Preventing repeated evaluations of subforms when
EVAL-WHENs are nested is unlikely to cause any serious compatibility
problems, since the current model would already result in only a
single evaluation in the case when the code is processed
interpretively.
There are also some situations concerning nested top-level occurences
of EVAL-WHEN that CLtL does not completely specify, to which this
proposal does assign a specific interpretation. For example, CLtL is
unclear on whether or not (FOO) would ever be called, while in the
current proposal it would definitely not be called:
(eval-when (compile)
(eval-when (compile)
(foo)))
Benefits:
Clarifying the meaning of EVAL-WHEN allows the behavior of defining
macros such as DEFMACRO to be specified in terms of EVAL-WHEN. As a
side effect, it would then become meaningful for defining macros to
appear at other than top-level.
Discussion:
This proposal reflects what appears to be the consensus of the
compiler cleanup committee on this issue.
-------
∂23-Sep-88 1055 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:55:13 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28959; Fri, 23 Sep 88 11:53:47 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02507; Fri, 23 Sep 88 11:53:43 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231753.AA02507@defun.utah.edu>
Date: Fri, 23 Sep 88 11:53:41 MDT
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL
To: x3j13@sail.stanford.edu
Issue: DEFINING-MACROS-NON-TOP-LEVEL
References: CLtL p. 66-70, 143
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Category: CLARIFICATION, ENHANCEMENT
Edit History: 6-May-88, V1 by Sandra Loosemore
9-Jun-88, V2 by Sandra Loosemore
12-Sep-88, V3 by Sandra Loosemore (fix garbled section 4)
21-Sep-88, V4 by Sandra Loosemore (clarify section 5)
Problem Description:
CLtL leaves the interpretation of defining forms such as DEFMACRO and
DEFVAR that appear in other than top-level locations unspecified.
Resolution of other issues (EVAL-WHEN-NON-TOP-LEVEL and
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS) now allows reasonable
semantics to be assigned to defining forms which appear at
non-top-level.
Proposal: DEFINING-MACROS-NON-TOP-LEVEL:ALLOW
(1) Clarify that while defining macros normally appear at top level,
it is meaningful to place them in non-top-level contexts and that the
compiler must handle them properly in all situations. Remove the
language on p. 66 of CLtL which states that the compiler is not
required to recognize defining macros at other than top-level.
(2) The proposal COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
defines a model for specifying how defining macros work. To
summarize, the expansion of the macro (rather than its expander
function) is responsible for storing information about the definition.
Compile-time side effects are typically handled by including one or
more EVAL-WHEN forms in the expansion. A compiler may choose
some other implementation, such as treating defining macros as
implementation-specific special forms, provided that the semantics
are compatible.
(3) Defining macros which define functional objects (such as DEFUN and
DEFMACRO) must ensure that the functions are defined in the lexical
environment in which the defining macro appears. In the model
referred to above, this would normally be implemented by producing a
FUNCTION special form in the macro expansion. For example, the
following code causes the function BAR to be closed over the variable
X:
(let ((x (some-hairy-computation)))
(defun bar (y) (+ x y)))
(4) The language on p. 145 of CLtL, which states that macro functions
are always defined in the null lexical environment, should be removed.
Instead, the defining forms DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and
the complex form of DEFSETF, which make functional definitions
available at compile time, use the environment which is apparent at
the time of evaluation. When calls to these macros appear in a
non-null lexical environment, an explicit (EVAL-WHEN (COMPILE) ...)
must normally be wrapped around the entire containing top-level form
to ensure that the correct lexical environment is seen at both compile
time and load time.
An example may help clarify why this is necessary. The code fragment
(let ((x (some-hairy-computation)))
(defmacro bar-macro (y) `(+ ,x ,y)))
would macroexpand into something similar to
(let ((x (some-hairy-computation)))
(eval-when (eval compile load)
(setf (macro-function 'bar-macro)
#'(lambda (form env)
(let ((y (second form)))
`(+ ,x ,y))))
'bar-macro))
Since the rules for (EVAL-WHEN (COMPILE) ...) state that evaluation
takes place in the null lexical environment, in this situation X would
be treated as a special variable within the macro function. However,
in the EVAL or LOAD situations, the lexical value of X would be used.
To ensure consistency, the correct definition would be:
(eval-when (eval compile load)
(let ((x (some-hairy-computation)))
(defmacro bar (y) `(+ ,x ,y))))
(5) Clarify that ``top-level forms'' are evaluable data objects read
in from an input source (such as a keyboard or disk file) by
successive calls to the function READ; these forms would be evaluated
by the interpreter in a null lexical environment. As special cases,
forms within a top-level PROGN or COMPILER-LET are also considered to
be top-level forms, as is the expansion of a macro call appearing at
top-level. Specify that top-level forms in a file being compiled are
guaranteed to be processed sequentially, but the order in which
subforms of a top-level form are processed by the compiler is
explicitly left unspecified. It is an error for user code to depend
upon the compile-time side-effects of a defining macro within the same
top-level form in which the defining macro appears.
Rationale:
The notion of a ``top-level form'' is rather confused, since the term
is used in CLtL to refer both to a place where a form may appear (what
this proposal continues to call ``top-level''), and to instances of
forms which traditionally appear there (what this proposal calls
``defining macros'').
There has been a suggestion that the notion of a top-level form should
be extended to include forms in the body of a top-level LET, to allow
forms such as DEFUN to be meaningful there. However, we feel that a
cleaner solution is to remove the restrictions on the placement of
defining macros altogether.
Current Practice:
CLtL mentions only that forms within a top-level PROGN, and not
COMPILER-LET, are treated as top-level. However, COMPILER-LET is
also treated specially in implementations derived from the MIT Lisp
Machine (TI and Symbolics), as well as Lucid and Coral (but not
VaxLisp).
Cost to implementors:
Cost to users:
None. This is a compatible extension.
Benefits:
The notion of defining macros as being somehow special is removed from
the language. Allowing defining macros to appear anywhere instead of
restricting them to certain positions results in a cleaner language
design.
Discussion:
-------
∂23-Sep-88 1055 X3J13-mailer issue COMPILE-ARGUMENT-PROBLEMS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:55:37 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28972; Fri, 23 Sep 88 11:54:12 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02512; Fri, 23 Sep 88 11:54:08 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231754.AA02512@defun.utah.edu>
Date: Fri, 23 Sep 88 11:54:07 MDT
Subject: issue COMPILE-ARGUMENT-PROBLEMS
To: x3j13@sail.stanford.edu
Issue: COMPILE-ARGUMENT-PROBLEMS
References: CLtL p. 438-439
Issue FUNCTION-TYPE
Issue DEFINING-MACROS-NON-TOP-LEVEL
Category: CLARIFICATION, CHANGE
Edit History: V1, Sandra Loosemore (8 Aug 1988)
V2, Sandra Loosemore (21 Sep 1988)
Problem Description:
The description of what arguments can legitimately be passed to the
function COMPILE in CLtL is too vague. There are two specific
problems:
(1) Acceptance of the FUNCTION-TYPE proposal makes it nonsensical to
speak of a lambda-expression being an interpreted function (it is not)
or to require a symbol to have a lambda-expression as its definition
(the SYMBOL-FUNCTION must be a true FUNCTION object).
(2) Many implementations cannot correctly compile functions that are
defined interpretively in a non-null lexical environment, because the
compiler and interpreter use different representations for closures.
Although this problem arose in conjunction with the
DEFINING-MACROS-NON-TOP-LEVEL proposal, the situation can also arise
if SETF is used to store a lexical closure in the SYMBOL-FUNCTION of
the symbol.
Proposal COMPILE-ARGUMENT-PROBLEMS:CLARIFY:
If the optional "definition" argument to COMPILE is supplied, it may
be either a lambda expression (which is coerced to a function) or a
function to be compiled. Otherwise, the SYMBOL-FUNCTION of the symbol
is extracted and compiled. It is an error if the function to be
compiled was defined interpretively in a non-null lexical environment,
or if it is already compiled.
Rationale:
Saying "it is an error" to try to compile the wrong kind of function
allows implementations that can compile functions defined in a
non-null lexical environment to go ahead and do so.
Current Practice:
Implementations that do not allow sharing of lexical environments
between compiled and interpreted functions include VaxLisp, Allegro
CL, and Lucid. Lucid and VaxLisp already accept an interpreted function
object as the "definition" argument to COMPILE.
Cost to implementors:
Most of the changes required for this proposal are already necessary
to correctly implement the FUNCTION-TYPE proposal. The primary addition
is that COMPILE must be extended to accept a FUNCTION object as well
as a lambda expression as the "definition" argument.
Cost to users:
None. This is an upward-compatible change, since a lambda expression
can still be passed as an argument to COMPILE. Also, since most
existing implementations refuse to compile a function with a non-empty
lexical environment, user code which depends on being able to do this
is already nonportable.
Benefits:
An area of ambiguity in the language is resolved.
Discussion:
An alternative behavior when trying to COMPILE as function that is
already compiled would be to do nothing.
-------
∂23-Sep-88 1056 X3J13-mailer issue COMPILE-FILE-PACKAGE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:56:00 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28982; Fri, 23 Sep 88 11:54:35 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02517; Fri, 23 Sep 88 11:54:31 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231754.AA02517@defun.utah.edu>
Date: Fri, 23 Sep 88 11:54:30 MDT
Subject: issue COMPILE-FILE-PACKAGE
To: x3j13@sail.stanford.edu
Issue: COMPILE-FILE-PACKAGE
References: CLtL p. 182, 183
Category: CHANGE, CLARIFICATION
Edit History: 1 Sep 1988, Sandra Loosemore (initial version)
21 Sep 1988, Sandra Loosemore (minor tweak to current practice)
Problem Description:
The variable *PACKAGE* is rebound by the function LOAD, so that its
old value will be restored in spite of any calls to IN-PACKAGE
appearing in the file being loaded. Since COMPILE-FILE must evaluate
any top-level calls to IN-PACKAGE that it sees, it may also alter the
value of *PACKAGE*. It is inconsistent to have COMPILE-FILE and LOAD
behave differently regarding the rebinding of this variable.
Proposal COMPILE-FILE-PACKAGE:REBIND:
Require COMPILE-FILE to rebind *PACKAGE* before processing the file.
Rationale:
This makes COMPILE-FILE and LOAD more consistent. It is a more
compatible solution than either requiring LOAD not to rebind
*PACKAGE*, or removing the specialness of IN-PACKAGE and the other
package functions.
Current Practice:
Lucid Common Lisp, the TI Explorer, and VaxLisp already implement this
proposal.
Cost to implementors:
Trivial.
Cost to users:
I find it hard to believe that users would consider COMPILE-FILE altering
the value of *PACKAGE* as a useful side effect.
Benefits:
The language is made more uniform.
Discussion:
-------
∂23-Sep-88 1056 X3J13-mailer issue OPTIMIZE-DEBUG-INFO
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:56:32 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28993; Fri, 23 Sep 88 11:55:10 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02522; Fri, 23 Sep 88 11:55:07 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231755.AA02522@defun.utah.edu>
Date: Fri, 23 Sep 88 11:55:06 MDT
Subject: issue OPTIMIZE-DEBUG-INFO
To: x3j13@sail.stanford.edu
Issue: OPTIMIZE-DEBUG-INFO
References: CLtL p. 160
Category: ADDITION
Edit History: V1 9 Sep 1988, David Gray (initial version)
V2 19 Sep 1988, David Gray (delete first alternative)
Problem Description:
The OPTIMIZE declaration provides a way to tell the compiler how important
various qualities are in order to guide which optimizations are done.
There is another quality, however, that is not mentioned, but is an
important consideration for the compiler: how much information
should be included in the object code to facilitate debugging. This
includes both annotation added to enable a debugger to display more
information to the user, and also suppression of optimizations that would
confuse debugging by making it harder to connect the object code with the
source code.
Proposal OPTIMIZE-DEBUG-INFO:NEW-QUALITY:
In the description of the OPTIMIZE declaration, add an additional quality
named DEBUG, described as "ease of debugging".
Rationale:
Since ease of debugging is an issue that the user will be concerned with,
and is an issue that the compiler needs to consider, this provides a clear
way for the user to control the amount of debugging information placed in
the object module, with DEBUG=0 meaning none and DEBUG=3 meaning "as much
as possible".
Current Practice:
No current implementation of this is known.
Cost to implementors:
All would have to update their handling of OPTIMIZE declarations to accept
the new quality.
Cost to users:
One more little feature to learn. Some problems may result from the
addition of the symbol DEBUG to the LISP package.
Benefits:
Provides users a standard way to control the interaction between
the compiler and debugger, and saves implementors from having to invent
implementation-dependent solutions.
Costs of Non-Adoption:
Continued confusion about how debug information should be controlled.
Discussion:
Concern has been raised that there is already a problem with the
non-orthogonality of SPEED, SAFETY, and SPACE that would be made even
worse with DEBUG added, since users tend to be perplexed by the
interactions of these qualities.
-------
∂23-Sep-88 1057 X3J13-mailer issue PROCLAIM-INLINE-WHERE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:57:11 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA29014; Fri, 23 Sep 88 11:55:45 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02527; Fri, 23 Sep 88 11:55:42 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231755.AA02527@defun.utah.edu>
Date: Fri, 23 Sep 88 11:55:41 MDT
Subject: issue PROCLAIM-INLINE-WHERE
To: x3j13@sail.stanford.edu
Issue: PROCLAIM-INLINE-WHERE
References: CLtL p. 156, 159
Category: CLARIFICATION
Edit History: 16 Sept. 88 V1 by David Gray
Problem Description:
CLtL does not specify whether a (PROCLAIM '(INLINE ...)) should come
before or after the DEFUNs that it refers to, but in most
implementations the compiler can't expand a function inline
unless it knows at the time it processes the DEFUN that the definition
needs to be saved for use in inline expansion.
Proposal PROCLAIM-INLINE-WHERE:BEFORE:
Clarify that (PROCLAIM '(INLINE ...)) tells the compiler both that it is
desirable to use inline expansion for calls to the functions indicated
and that the compilation of any subsequent DEFUN of one of the functions
should record whatever information is used for performing inline
expansions. Consequently, the proclamation should precede the
definition of the functions that it names. When compiling a function
call, if the function has been proclaimed INLINE but the current
definition of the function was established before the PROCLAIM was
processed, it is implementation-dependent whether the function will
actually be expanded inline.
Rationale:
This clarification brings the specification in line with current
practice. The only alternative would appear to be to require the
compiler to always save the definition of every function, and that
doesn't seem reasonable.
Test Cases/Examples:
Given the following input to COMPILE-FILE, does F1 get expanded inline
in F2?
(defun f1 (a) (+ a 100))
(proclaim '(inline f1))
(defun f2 (b) (f1 b))
Current Practice:
The documentation for Lucid and the TI Explorer both say that INLINE
proclamations need to precede the function definition. Symbolics
doesn't appear to document this, but requires it anyway. Thus none of
these three implementations do the inline expansion in the example
above.
Cost to implementors:
Probably none required, although given this clarification it would be
nice if compilers warned about an INLINE proclamation that follows the
indicated DEFUN in the same file.
Cost to users:
None.
Benefits:
Users will know how to use INLINE proclamations correctly.
Costs of Non-Adoption:
Continued confusion over cases such as the example above, which
conform to CLtL but don't do what is expected.
Discussion:
-------
∂23-Sep-88 1058 X3J13-mailer **DRAFT** issue COMPILE-ENVIRONMENT-CONSISTENCY
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:57:54 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA29038; Fri, 23 Sep 88 11:56:26 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02532; Fri, 23 Sep 88 11:56:23 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231756.AA02532@defun.utah.edu>
Date: Fri, 23 Sep 88 11:56:22 MDT
Subject: **DRAFT** issue COMPILE-ENVIRONMENT-CONSISTENCY
To: x3j13@sail.stanford.edu
Issue: COMPILE-ENVIRONMENT-CONSISTENCY
References: CLtL p. 68-69, 143, 321
RAM's "Compiler Cleanup Proposal #3"
Category: CLARIFICATION
Edit History: V1, 2 Sep 1988, Sandra Loosemore (initial draft)
V2, 9 Sep 1988, Sandra Loosemore (incorporate suggestions)
Status: **DRAFT**
Problem Description:
CLtL does not clearly specify what aspects of the compiletime
environment the compiler (or other preprocessor) may "wire in" to code
being compiled.
Proposal COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY:
Common Lisp deliberately leaves unspecified the time at which certain
transformations, such as macro expansion, are performed within a
program. While some implementations perform such transformations
concurrently with evaluation, it is also legitimate to perform
transformations during a preprocessing phase. For example, an
implementation might choose to apply transformations at "function
promotion time" (i.e., transformations are applied once during
evaluation of a surrounding FUNCTION special form), or to completely
transform each top-level form and all of its subforms before
performing any evaluation. User programs cannot portably depend upon
either the time of such transformations, or the number of times the
transformations are applied.
In all cases, however, compiling a program (with COMPILE or
COMPILE-FILE) provides a mechanism for forcing these transformations
to be applied and a guarantee that, once compiled, no further
transformations will be applied to that program.
In the discussion that follows, the term "compiler" is to be understood
to include other preprocessors as well. Likewise, the "compiletime
environment" refers to the environment in which program transformations
occur, while "runtime" refers to the time the program is executed.
(1) The following information *must* be present in the compiletime
environment for the preprocessor to apply the correct transformations.
This information need not also be present in the runtime environment.
(a) Macro definitions must be available in the compiletime environment.
The compiler may assume that forms that are lists beginning with
a symbol that does not name a macro or special form is a function
call. (This implies that SETF methods must also be available at
compiletime.)
(b) Special variables must be declared as such before they are bound.
The compiler must treat any undeclared variable binding as a
lexical binding.
(2) The compiler *may* "wire in" the following kinds of information
into the code it produces, if the information is present in the
compiletime environment. However, since implementations are not
required to do this, user code must ensure that the information is
also defined consistently in the runtime environment. Except as
noted, the behavior of user programs is unspecified in situations
where the information is defined differently at runtime than at
compiletime, since the user cannot depend upon which will take
precedence in a particular implementation. In all cases, the absence
of the information at compiletime is not an error, but its presence
may enable the compiler to do a better job.
(a) The compiler may assume that functions that are defined and
declared INLINE in the compiletime environment will retain the
same definitions at runtime.
(b) The compiler may assume that, within a named function, a
recursive call to a function of the same name refers to the
same function, unless that function has been declared NOTINLINE.
(c) COMPILE-FILE may assume that, in the absence of NOTINLINE
declarations, a call within the file being compiled to a named
function which is defined in that file refers to that function.
(This permits "block compilation" of files.) The behavior of
the program is unspecified if functions are redefined individually
at runtime.
(d) The compiler may assume that the signature (or "contract") of
all built-in Common Lisp functions will not change. In addition,
the compiler may treat all built-in Common Lisp functions as if
they had been proclaimed INLINE.
(e) The compiler may "wire in" the values of symbolic constants
that have been defined with DEFCONSTANT in the compiletime
environment.
(f) Types that are defined with DEFTYPE or DEFSTRUCT can be assumed to
retain the same definition in the runtime environment as in the
compiletime environment. (Note that it is not an error for an
unknown type to appear in a declaration at compiletime, although
it is reasonable for the compiler to emit a warning in such a
case.)
(g) The compiler may assume that a class name defined by DEFCLASS
that is present in the compiletime environment will also be a
class name at runtime, and that class will be an instance of the
same metaclass. There may be additional conformance requirements
imposed by the metaclass, but there are none for STANDARD-CLASS.
(h) The compiler may assume that if type declarations are present
in the compiletime environment, the corresponding variables and
functions present in the runtime environment will actually be of
those types; otherwise, the behavior of the program is undefined.
(3) The compiler *must not* make any additional assumptions about
consistency between the compiletime and runtime environments. In
particular:
(a) The compiler may not assume that functions that are defined
in the compiletime environment will retain the either the
same definition or the same signature at runtime, except
in situations (2a) through (2d) above. It is, however,
reasonable for the compiler to emit warning messages about
calls to functions that are defined at compiletime, but where
the wrong number or type of arguments are supplied.
(b) The compiler may not signal an error if it sees a call to a
function that is not defined at compiletime, since that function
may be provided at runtime. Again, it is permissible to emit
a warning in these situations.
Rationale:
This proposal generally reflects current practice.
Current Practice:
I know of no compiler that does not implement the provisions of item (1).
For item (2), most compilers (including Lucid) optimize self-recursive
calls by default. Most compilers also opencode data structure
accessors (such as CAR) at some level of optimization, and some code
much more complicated built-in functions inline as well. VaxLisp, for
example, normally compiles MEMBER inline. The Lucid compiler makes
use of type declarations to perform generic-to-specific
transformations on many arithmetic and sequence functions, which is
also a form of inlining. KCL performs block compilation by default,
and Lucid does so under certain conditions.
Cost to implementors:
Unknown, but probably minor.
Cost to users:
Since most implementations appear to be largely in conformance with the
proposal, users should notice little difference.
Benefits:
The presence of a definite specification of what may happen when will
help users structure their programs so they will compile correctly in
all Common Lisp implementations.
Discussion:
Most of the discussion on this issue has been centered on the
terminology describing error situations for item (2). In most cases
where there is an inconsistency between compile-time and run-time, the
results will be unpredictable but harmless. The major exception is
violation of type declarations, which is a "crash-and-burn" error in
many implementations.
There has also been some concern raised that item (3) would prohibit
such things as a cross-compiler that produces standalone programs in
an environment that disallows redefinition of functions. The intent
of this proposal is not to prohibit a compiler from having a magic
switch that imposes additional restrictions on the programs it
compiles, but such a compiler would not be a compiler for Common Lisp.
-------
∂23-Sep-88 1058 X3J13-mailer **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:58:36 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA29064; Fri, 23 Sep 88 11:57:04 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02537; Fri, 23 Sep 88 11:57:00 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231757.AA02537@defun.utah.edu>
Date: Fri, 23 Sep 88 11:56:59 MDT
Subject: **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE
To: x3j13@sail.stanford.edu
Issue: PROCLAIM-ETC-IN-COMPILE-FILE
References: CLtL p. 182 [package functions],
p. 156 [PROCLAIM], P. 188 [REQUIRE],
p. 439 [COMPILE-FILE];
Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Category: CLARIFICATION
Edit History: 15 Sept. 88, V1 by David Gray
23 Sep 88, V2 by Sandra Loosemore (summarize discussion)
Status: **DRAFT**
Problem Description:
Page 182 of CLtL says that COMPILE-FILE needs to treat top-level calls
to the following package functions as though they were wrapped in an
(EVAL-WHEN (COMPILE LOAD EVAL) ...):
EXPORT IMPORT IN-PACKAGE MAKE-PACKAGE SHADOW
SHADOWING-IMPORT UNEXPORT UNUSE-PACKAGE USE-PACKAGE
There are other things that need special handling by the compiler that
are not explicitly specified by CLtL. The proposal
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY addresses the part of
the problem pertaining to macros that define things. The following
proposal adds PROCLAIM and REQUIRE to the list of functions needing
special handling.
Proposal PROCLAIM-ETC-IN-COMPILE-FILE:CLARIFY:
Clarify that when COMPILE-FILE encounters a call to one of the following
functions at top level in a file, the form will be evaluated at compile
time as well as at load time:
EXPORT IMPORT IN-PACKAGE MAKE-PACKAGE PROCLAIM REQUIRE SHADOW
SHADOWING-IMPORT UNEXPORT UNUSE-PACKAGE USE-PACKAGE
Note that the compile-time evaluation of these package functions can
affect the way that the remaining top-level forms in the file are read.
In the case of PROCLAIM, it is implementation-dependent whether the
evaluation affects the global environment or is only recorded in data
structures used by the compiler, and whether the effect of the
evaluation remains in the global environment after COMPILE-FILE returns.
(PROCLAIM '(OPTIMIZE ...)) is a special case that is evaluated only at
compile-time and not at load time, and that affects only the current
file being compiled.
Note that the behavior specified here can still be altered by the
user by wrapping an explicit EVAL-WHEN around the form.
Rationale:
Experience seems to have shown that this behavior best matches what
people expect to have happen. The examples on pages 189 and 191 of CLtL
won't work right unless REQUIRE takes effect at compile-time. Since
most of the things that PROCLAIM can be used for only affect the
compiler, it doesn't make much sense for the compiler to not take notice
during compilation. Optimization control is something that one usually
wants to control locally, rather that having a proclamation in one file
affect other unrelated files compiled later.
Current Practice:
This proposal follows what the Explorer does, except that (EVAL-WHEN
(LOAD) (PROCLAIM '(OPTIMIZE ...))) doesn't do anything. The Symbolics
compiler has special top-level handling for all of these functions,
although the details are not clear. The Lucid documentation indicates
that certain functions at top-level are treated as though within an
(EVAL-WHEN (EVAL COMPILE LOAD) ...): REQUIRE, all of the package
functions listed above, INTERN, and UNINTERN; it is not clear what
happens with PROCLAIM.
Cost to implementors:
Since implementations are already required to have a mechanism for
compile-time handling of the package functions, it should only require
minor adjustments to add handling for PROVIDE and REQUIRE if they aren't
handled already. The main thing that most implementations would need to
do is to make OPTIMIZE proclamations local to the file, but that should
be fairly simple.
Cost to users:
If someone has a use of REQUIRE that they want to only be a load-time
dependency and their implementation did not previously do REQUIRE at
compile-time, they may want to wrap (EVAL-WHEN (EVAL LOAD) ...) around
it.
If someone has a use of (PROCLAIM '(OPTIMIZE ...)) that they really want
to be global, they would need to wrap (EVAL-WHEN (EVAL COMPILE LOAD)
...) around it.
Benefits:
Users will know what to expect when they use PROCLAIM and REQUIRE.
Costs of Non-Adoption:
In order to write programs that would be sure to be portable, the user
would have to wrap an (EVAL-WHEN (EVAL COMPILE LOAD) ...) around each use
of PROCLAIM or REQUIRE in order to be sure of what will happen.
Aesthetics:
Programs look cleaner if EVAL-WHEN is only needed for unusual cases
instead of being required for the normal cases.
Discussion:
Cleanup proposal PROCLAIM-SCOPE:ADD-KEYWORD-PERVASIVE wanted to add an
option to PROCLAIM to control whether the effect is local to the current
file. That may be better handled by an extension to EVAL-WHEN since
that kind of control might be wanted for definitions as well as
proclamations. If the handling of OPTIMIZE specified here is taken as a
default, that issue can be pursued separately from this one.
There have been objections raised to treating (PROCLAIM '(OPTIMIZE...))
specially.
If DEFPACKAGE is accepted, we may wish to remove the "magical" behavior
of the package functions entirely, and propose a macro (DEFPROCLAIM?)
to deal with PROCLAIM. How do people feel about making this kind of
incompatible change to the language?
-------
∂23-Sep-88 1212 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 23 Sep 88 12:12:09 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Fri, 23 Sep 88 15:11:42 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 23 Sep 88 15:09:39 EDT
Date: Fri, 23 Sep 88 15:10 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8809231753.AA02507@defun.utah.edu>
Message-Id: <19880923191014.6.BARMAR@OCCAM.THINK.COM>
Date: Fri, 23 Sep 88 11:53:41 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Specify that top-level forms in a file being compiled are
guaranteed to be processed sequentially, but the order in which
subforms of a top-level form are processed by the compiler is
explicitly left unspecified. It is an error for user code to depend
upon the compile-time side-effects of a defining macro within the same
top-level form in which the defining macro appears.
I don't understand this part. Could you give an example of code that
has such a dependency?
barmar
∂23-Sep-88 1309 @Score.Stanford.EDU:WASHINGTON@SUMEX-AIM.Stanford.EDU CSD orientation brunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Sep 88 13:09:25 PDT
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 23 Sep 88 13:05:42-PDT
Date: Fri, 23 Sep 88 13:02:47 PDT
From: Rich Washington <washington@SUMEX-AIM.Stanford.EDU>
Subject: CSD orientation brunch
To: faculty@score.Stanford.EDU
Message-ID: <12432922447.47.WASHINGTON@SUMEX-AIM.Stanford.EDU>
The orientation brunch for new computer science graduate
students will be this Sunday, September 25, 11 AM - 1 PM,
at Richard Waldinger's house in Palo Alto. You are invited
and encouraged to come and meet the new PhD and Master's
students and help welcome them to the department. To sweeten
the deal, we will be providing food and drink.
The Waldingers' house is at 1033 Bryant, near Embarcadero.
From Stanford, take Embarcadero under the Alma underpass,
and take the first legal left turn, onto Bryant (the first
street is Ramona, but left turns are prohibited). Go two
blocks on Bryant, and 1033 Bryant is the second house on the
right after Lincoln St.
From Highway 101, take Embarcadero towards Stanford, turning
right on Bryant (one block after the light at Waverly). Go
two blocks on Bryant, and 1033 Bryant is the second house on
the right after Lincoln St.
We'll hope to see you on Sunday.
CSD Orientation Committee
-------
∂26-Sep-88 0927 TOM@Score.Stanford.EDU SAIL is Down
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Sep 88 09:27:41 PDT
Date: Sun 25 Sep 88 16:49:34-PDT
From: Thomas Dienstbier <TOM@Score.Stanford.EDU>
Subject: SAIL is Down
To: su-computers@Score.Stanford.EDU
cc: faculty@Score.Stanford.EDU, staff@Score.Stanford.EDU
Message-ID: <12433488022.14.TOM@Score.Stanford.EDU>
SAIL is down due to a faulty box of memory. We should have it operational
tomorrow.
-------
∂26-Sep-88 0930 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu New Role for Donald Knuth
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Sep 88 09:30:28 PDT
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 26 Sep 88 08:07:19-PDT
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA05251; Mon, 26 Sep 88 08:01:42 PDT
Date: Mon, 26 Sep 88 08:01:42 PDT
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8809261501.AA05251@Tenaya.stanford.edu>
To: faculty@score
Subject: New Role for Donald Knuth
Effective January 1, 1990, Stanford will appoint Donald E. Knuth
Professor of the Art of Computer Programming. In recognition of the
unique importance of his publications to the foundations of computer
science, Knuth's role will be to devote essentially all of his time to
writing the remaining volumes of the widely acclaimed work having that
title. Realizing that the first three volumes are recognized
worldwide as a sort of bible of computer science, and that completion
of four additional volumes may well take another twenty years of
scholarly activity, the University believes that the the best
traditions of science, engineering, and education will be served if
Knuth is released from his normal duties to devote full time to this
project.
People familar with Knuth's considerable energy and love of hard work
will not find it surprising that he intends to continue making
important contributions to Stanford's educational program, but in an
innovative way linked to University traditions of the past. Don
expects to lead a non-credit seminar, open to all and meeting about
once a week, to lecture on and to discuss topics arising from his book
writing.
To strengthen its capacities for continuing leadership, the Department
intends to initiate a search soon to find a suitable successor to
Knuth in his present role as Fletcher Jones Professor of Computer
Science.
-Nils
∂26-Sep-88 0931 X3J13-mailer issue EVAL-WHEN-NON-TOP-LEVEL
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88 09:31:16 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 465233; Sun 25-Sep-88 15:09:13 EDT
Date: Sun, 25 Sep 88 15:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue EVAL-WHEN-NON-TOP-LEVEL
To: sandra%defun@cs.utah.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8809231753.AA02502@defun.utah.edu>
Message-ID: <880925150859.4.KMP@GRYPHON.SCRC.Symbolics.COM>
I'm sorry. At the last meeting, I stated that I had reservations about
this proposal and said I would send some mail and I never did. I did say
at that time, though, that the root of my problem was that there were
insufficient examples and that this made me nervous because this is a
hard issue to reason about and (I think) an easy one to get wrong.
-- Specific Remarks --
Your use of phrases like "the interpreter" in the proposal make me
nervous because I work with at least one compiled-only implementation
(Cloe).
Your remarks about
(let ((x (some-hairy-computation)))
(eval-when (eval compile load) (print x)))
treating X as special in the compile situation are not supported by any
part of CLtL that I know of. X is treated as "free", but that situation
is not defined by CLtL as far as I know.
Btw, I don't see why the term "hairy" needs to be in that example.
The issue would be the same for a trivial computation.
Your references to EVAL being like "normal processing of the interpreter"
and LOAD being like "normal processing of the compiler" are too obscure
for me to figure out. Perhaps you mean "normal execution of interpreted
code" and "normal execution of compiled code"? If so, I might begin to see
what you mean, but since the presence of compiled-only and interpreted-only
implementations makes these phrases vague, I'd want to see this clarified.
I am also unconvinced that LOAD really corresponds to "normal execution".
In my code, it often addresses things that really only want to be done
once and never again because at top-level, things can't happen more than
once. I'm not at all clear that if I had a DEFFOO macro which expanded
into (EVAL-WHEN (LOAD) ...) and someone put the DEFFOO in the body
of (DEFUN BAR ...) -- a thing you're apparently advocating -- that I
would want the thing in the LOAD clause executing every time they called
BAR.
Also, you don't offer enough info for me to figure out what happens when
both EVAL and LOAD are specified in the interpreter.
In general, the absence of examples makes this just hard to follow.
-- General Remarks --
I believe that the real problem with EVAL-WHEN is that its keywords do
not map straightforwardly onto the things we really need to say. For
example, when we really want to do something abstract like "provide
macro support at semantic analysis time" we are instead forced to
designate times (EVAL COMPILE) because we happen to know that that is
when semantic analysis takes place and we must cover our bets.
I think there is no fix for EVAL-WHEN other than to identify keywords
which are equally meaningful to interpreter-only and compiled-only
implementations. I would rename COMPILE to something meaning ``semantic
analysis time,'' LOAD to something meaning ``first occurrence in
execution environment'' and EVAL to mean something like ``execution
time.'' But then I would also want to require interpreted-only
implementations to do a semantic-prepass so that ``semantic analysis
time'' where all macros were expanded at once and all EVAL-WHEN's
figured out at a definite time rather than being permitted to occur
lazily.
Since I don't really feel convinced about what you're proposing and since
I think what I might propose is a ``research'' project too ambitious
to get into at this point, I would prefer that EVAL-WHEN continue to
be illegal except at toplevel and that we just pin down a status-quo
description of what EVAL-WHEN already does, asking Kathy to acknowledge
in the manual that we know its design is less than pretty and that
the design of a better primitive is a research topic.
∂26-Sep-88 0931 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88 09:31:39 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 465246; Sun 25-Sep-88 16:59:01 EDT
Date: Sun, 25 Sep 88 16:58 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4)
To: sandra%defun@cs.utah.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8809231753.AA02507@defun.utah.edu>
Message-ID: <880925165852.8.KMP@GRYPHON.SCRC.Symbolics.COM>
Since this proposal is apparently (although not explicitly) dependent on
your EVAL-WHEN-NON-TOP-LEVEL:CLARIFY, and since I don't support that
proposal, it shouldn't come as a surprise that I can't support this one.
In addition to whatever comments might carry through from my objections
to that proposal, however, I also have these concerns:
* I don't think the nesting under the proposed definition of DEFMACRO
is consistent. Consider:
(DEFUN FOO ...
(DEFMACRO BAR ...))
Under your proposed EVAL-WHEN semantics, the definition of BAR will
be available at compile time for all forms following FOO's definition,
but it will not become available at runtime until FOO is called.
This strikes me as very baroque.
* We have a charter to do something about establishing normative
practice. When McCarthy was visiting, he suggested that one thing
that goes with that is making sure that if you're encouraging people
to do something, it's something you can reasonably expect to support
efficiently. It follows, I think, that if you change the language
to encourage people to do DEFUN inside of DEFUN, DEFMETHOD inside of
DEFMETHOD, etc., you'd better make it efficient. In fact, though,
many implementations do lots of "junk" at compiled file load time
which you wouldn't want executed every time you ran a function.
* For the most part, it doesn't make any sense to do
(DEFUN ... (DEFUN ...)) so it seems strange to encourage it.
The only practical reason I can think of for doing this is to do
some sort of module facility where you selectively activate definitions
that you need by calling the outer function. I think this is what
LOAD and packages are already in CL for, and although I don't think they
are the answer to all the world's problems, they are better than
doing nested defuns.
* The Scheme language attaches a very different meaning to
(DEFUN FOO (X)
(DEFUN BAR (X) ...) ... (BAR ...) ...)
than we do. I've seen novices screwed by doing this and having it work.
[It does in most interpeters.] They -think- they are getting a local
function when really they're getting BAR globally redefined every time
they run FOO. They don't find out until they do
(DEFUN BAZ (X)
(DEFUN BAR (X) ...) ... (BAR ...) ...)
and start calling FOO and BAZ in complicated, mutually recursive situations
with BAR getting clobbered back and forth until disaster finally strikes.
The CL style for local definitions is LABELS, FLET, etc. and I think
we should just stick to that.
I don't pretend that these are all the objections that I would have if I
thought for more than ten minutes on this issue, but they seem to me to
be sufficiently major to warrant some pretty careful thought before
proceeding on this.
I would prefer that defining forms just be restricted to toplevel
because we don't have time in the next three months to do any better
than that.
∂26-Sep-88 0931 X3J13-mailer issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88 09:31:39 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 465244; 25 Sep 88 16:41:52 EDT
Date: Sun, 25 Sep 88 16:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
To: sandra%defun@cs.utah.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8809231752.AA02497@defun.utah.edu>
Message-ID: <880925164139.7.KMP@GRYPHON.SCRC.Symbolics.COM>
Sorry about the delay in replying. I have a number of comments
about this proposal...
Date: Fri, 23 Sep 88 11:52:35 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Subject: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Ultimately, I expect to support this proposal though I have some
reservations about many sections in the current draft...
(1) Clarify that defining macros such as DEFMACRO or DEFVAR, ...
A convenient model for explaining how these side effects happen is
that the defining macro expands into one or more EVAL-WHEN forms ...
This is also the recommended implementation technique.
This last sentence is gratuitous. It adds nothing to the proposal
and makes me very nervous. For example:
(PROGN (PROCLAIM '(SPECIAL *WHATEVER*))
(SETQ *WHATEVER* 3))
is a better expansion for DEFVAR than anything involving EVAL-WHEN.
As another example, many implementations get by fine with DEFUN
turning into
(SETF (SYMBOL-FUNCTION 'WHATEVER) #'(LAMBDA ...))
DEFTYPE: The body of a DEFTYPE form must be evaluable at compile time.
If the expansion of a DEFTYPE'd type specifier is also a valid type
specifier at compile time, then the DEFTYPE'd type specifier is also
considered to be fully defined at compile time and must be recognized
within subsequent type declarations.
If it uses SATISFIES of a named, user-defined function in its expansion,
must the function be available at compile time for the type specifier to
be considered `valid' ? Can/should implementations give an undefined-function
warning at compile time?
DEFMACRO, DEFINE-MODIFY-MACRO: Macro definitions must be stored at compile
time, so that occurences of the macro later on in the file will be expanded
"occurrences"
correctly. The body of the macro (but not necesarily its expansion) must
"necessarily"
be evaluable at compile time.
Whether the expansion is necessary depends on whether the macro is itself used
subsequently in the file in the body of another macro being defined. eg,
(DEFMACRO FOO ...)
(DEFUN BAR-FUNCTION ... (FOO ...)) ;Needs FOO body
(DEFMACRO BAR-MACRO ... (FOO ...)) ;Needs FOO body and expansion
By similar reasoning, whether the macro body needs to be executable is not a
given. You might not plan to use the macro in the remainder of the file, in which
case it need only be compilable but not executable until load time.
The two situations seem symmetric to me in this respect, so I don't understand
the use of the asymmetric construction "The body ... (but not necesarily its
expansion) must ...".
DEFUN: An implementation may choose to store information about the
function for the purposes of compile-time error-checking (such as
checking the number of arguments on calls), or to enable the function
to be expanded inline. Portable code should not rely on DEFUN making
the function definition available at compile time.
Does this imply that it's permitted? That may make sense for COMPILE, but
it doesn't make sense for COMPILE-FILE. COMPILE-FILE should be a no-op (or
a ``copy-file'' equivalent) in interpreter-only implementations. There should
be no side-effect of doing COMPILE-FILE, so that (COMPILE-FILE "A") followed
by (LOAD "A") will load "A" only once.
DEFVAR, DEFPARAMETER: The compiler must recognize that the variables
named by these forms have been proclaimed special. The initial value
form must not be evaluated at compile time.
DEFCONSTANT: The compiler must recognize the symbol as being constant
This sentence is pretty vacuous unless you intend to make the "for example"
items that follow into requirements (which would make this an incompatible
change for some). Do you really mean to imply anything useful by this
sentence and if so, what?
(for example, to suppress warnings about references to the symbolic
constant as an unbound variable or to enable warnings about binding or
SETQ'ing the constant in the code being compiled).
I assume these are just examples and not something you're trying to require.
Be clear.
Neither evaluation
of the value-form or SETQ'ing of the symbol may occur at compile-time.
My guess is that this might be an incompatible change for some environments.
I think some implementations permit
(DEFCONSTANT FOO 3)
(DEFCONSTANT BAR (+ FOO 1))
The effects of incompatible changes aren't really addressed adequately in
the subsequent sections. Rather than CLARIFICATION for category above, you
might want to write CLARIFICATION/CHANGE to alert people to the fact that
some (technically "non-portable", but possibly "intended to be portable")
code may be affected.
However, if the (unevaluated) value-form is CONSTANTP, the compiler is
allowed to build assumptions about the value of the constant into
programs being compiled, as described on p. 68-69 of CLtL.
DEFSETF, DEFINE-SETF-METHOD: SETF methods must be available during the
expansion of calls to SETF later on in the file. The body of
DEFINE-SETF-METHOD and the complex form of DEFSETF must be evaluable
at compile time, although the expansions need not be.
As with DEFMACRO, this depends on whether this SETF is used in the remainder
of the file. In general, I find this wording awkward because the first sentence
is a restriction on the compiler and the second is a restriction on the user
and they're just haphazardly mixed together. This isn't the only place where
that happens in this topic writeup.
DEFSTRUCT: The structure type name must be recognized as a valid type name
in declarations, as for DEFTYPE. The structure slot accessors must be made
"in subsequent declarations" ?
known to SETF. In addition, further DEFSTRUCT definitions should be able
to :INCLUDE a structure type defined earlier in the file being compiled.
The functions which DEFSTRUCT generates, and the #S reader syntax, may or
may not be available at compile time.
I'm not sure it's wise to be ambiguous on this. What's the motivation here?
(3) The compile-time side effects may cause information about the
definition to be stored differently than if the defining macro had
been processed in the "normal" way (either interpretively or by loading
the compiled file).
... In particular, ...
If you mean that
(DEFMACRO FOO ...)
(DEFMACRO BAR ... (FOO ...))
is not permissible, again your are talking [a fairly major] incompatible change
to some implementations for which you've insufficient cost analysis.
Rationale:
The proposal reflects standard programming practices.
With one or two notable exceptions, cited above.
... Current Practice: ...
Kyoto Common Lisp is a notable offender.
This statement is not adequately qualified and somewhat inflammatory.
Your current practice statement would be no less complete and somewhat
more diplomatic if you just struck this sentence altogether.
... Cost to implementors: ...
Making the defining macros expand into EVAL-WHENs to store the required
information is a simple and recommended implementation technique.
What's easy (or even desirable) in one implementation may not be in another.
I don't think you've motivated this statement adequately.
Cost to users:
Since CLtL does not specify whether and what compile-time side-effects
happen, any user code which relies on them is, strictly speaking,
nonportable. In practice, however, most programmers already expect
the behavior described in this proposal and will not find it to be
an incompatible change.
Not so in all cases. See remarks above.
Benefits:
Adoption of the proposal will provide more definite guidelines on how to
write programs that will compile correctly under all CL implementations.
I agree with the intent here, but until the issues raised above have been
addressed, I can't agree with the specifics.
Discussion:
Reaction to an earlier version of this proposal on the CL mailing list was
overwhelmingly positive....
Please don't take my reaction as negative, but don't count me as overwhelmingly
positive either.
∂26-Sep-88 0931 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu faculty lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Sep 88 09:31:28 PDT
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 26 Sep 88 08:12:58-PDT
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA05260; Mon, 26 Sep 88 08:07:23 PDT
Date: Mon, 26 Sep 88 08:07:23 PDT
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8809261507.AA05260@Tenaya.stanford.edu>
To: faculty@score
Subject: faculty lunch
As Joyce has already mentioned, our first faculty lunch of Fall
Quarter will be tomorrow (Tuesday). I haven't planned any particular
discussion topic---thinking it would be pleasant just to get together
as a group, meet our new faculty members and greet returning people.
12:15 in MJH 146.
Next week, Oct 4, the faculty lunch topic will be the new buildings,
and our guest will be Ted Brown, our architect. Also attending,
probably, will be Dean Jim Gibbons and some university staff people
concerned with the building project. Ted will bring some models of
proposed buildings.
-Nils
∂26-Sep-88 1041 X3J13-mailer Re: issue EVAL-WHEN-NON-TOP-LEVEL
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 26 Sep 88 10:41:39 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
id AA00628; Mon, 26 Sep 88 10:37:14 PDT
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0)
id AA16788; Mon, 26 Sep 88 10:40:00 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA18918; Mon, 26 Sep 88 10:39:55 PDT
Message-Id: <8809261739.AA18918@suntana.sun.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: sandra%defun@cs.utah.edu, x3j13@sail.stanford.edu
Subject: Re: issue EVAL-WHEN-NON-TOP-LEVEL
In-Reply-To: Your message of Sun, 25 Sep 88 15:08:00 -0400.
<880925150859.4.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Mon, 26 Sep 88 10:39:52 -0700
From: kempf@Sun.COM
>analysis time,'' LOAD to something meaning ``first occurrence in
>execution environment'' and EVAL to mean something like ``execution
Or LOAD should mean something like "mapping of relative addresses
to absolute physical addresses", i.e. linking of separately compiled
code.
I agree that this is a thorny issue which needs more thought and
think EVAL-WHEN should remain illegal except at "top level" as
it currently is.
jak
∂26-Sep-88 1136 @Score.Stanford.EDU:chandler@polya.Stanford.EDU 9/27/88 Faculty Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Sep 88 11:36:42 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 26 Sep 88 11:32:24-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA27446; Mon, 26 Sep 88 11:33:09 PDT
Date: Mon, 26 Sep 1988 11:32:55 PDT
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score, chandler@polya.Stanford.EDU,
jle@pescadero, lam@mojave
Subject: 9/27/88 Faculty Meeting
Message-Id: <CMM.0.87.591301975.chandler@polya.stanford.edu>
I. Approval of degree candidates, Sharon Hemenway
II. Staff Reports
A. Computer Forum
Carolyn Tajnai
B. Department Finances
Betty Scott
C. Department Secretarial Policy
Betty Scott
D. Educational Affairs
Roy Jones
E. Computer Facilities
Jim Ball
III. Other Reports (Short Summaries)
A. Information Sciences Building
Nils Nilsson
B. Meeting Between PhD Students and Faculty
Nils Nilsson and Tom Henzinger
C. CSD 1988/1989 Committees
(Remarks About Comprehensive, Curriculum, PhD,
Visiting Prof., and Colloquium Committees)
Nils Nilsson
D. Department "Spokespeople"
Nils Nilsson
IV. Promotion and Appointment Items
A. Promotion of Research Associate Jean Ponce to
Senior Research Associate (Refer to separately
distributed memo and vitae)
Tom Binford
B. Renewal of Courtesy Faculty Appointments:
Michael Flynn, Professor, Electrical Engineering
John Gill, Assoc. Professor, Electrical Engineering
Edward Shortliffe, Assoc. Professor, Medicine
Fouad Tobagi, Professor, Electrical Engineering
David Ungar, Assistant Professor, Electrical Engineering
C. Renewal of Consulting Faculty Appointments
Patrick Hayes, Consulting Professor, Schlumberger
Fernando Pereira, Consulting Assoc. Professor, SRI
Marty Tenenbaum, Consulting Professor, Schlumberger
D. New Consulting Faculty Appointments
Susan Owicki, Consulting Professor, Digital
Brian Reid, Consulting Assoc. Professor, Digital
Bill Clancey, Consulting Assoc. Professor, IRL,
(Institute for Research and Learning)
E. Report on Asst. Chair for Education Search
Nils Nilsson
F. Reports on Searches in Progress
Knuth, Hennessy, Latombe, Oliger
IV. Other
∂26-Sep-88 1203 X3J13-mailer Hawaii hotel arrangements
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 Sep 88 12:03:20 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA09281g; Mon, 26 Sep 88 11:01:19 PST
Received: by challenger id AA13605g; Mon, 26 Sep 88 11:59:03 PDT
Date: Mon, 26 Sep 88 11:59:03 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809261859.AA13605@challenger>
To: X3J13@sail.stanford.edu
Subject: Hawaii hotel arrangements
We have a block of rooms reserved the 14th - 22nd of January at the Sheraton
for $80/night. Unless I change these dates you will be charged $120/night for
any dates before or after the reserved block (I know, they're bogones). If
you are planning to be there longer than the week of the conference (or arrive
earlier) please let me know ASAP what those dates are so I can try to adjust
the block to include those dates. I have to call them back Thursday morning.
Aloha,
---jan---
∂26-Sep-88 1632 @Score.Stanford.EDU:mayr@polya.Stanford.EDU change of address
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Sep 88 16:32:15 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 26 Sep 88 16:28:24-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA18802; Mon, 26 Sep 88 16:26:23 PDT
Date: Mon, 26 Sep 1988 16:26:20 PDT
From: Ernst Mayr <mayr@polya.stanford.edu>
To: change-of-address@polya.Stanford.EDU
Subject: change of address
Message-Id: <CMM.0.87.591319580.mayr@polya.stanford.edu>
As of October 1, 1988, my address is
Ernst Mayr
Fachbereich Informatik (20)
Johann Wolfgang Goethe-Universitaet
Postfach 11 19 32
Robert-Mayer-Str. 11--15
D-6000 Frankfurt am Main 11
West Germany
E-mail (direct): unido!rbiffm!mayr@uunet.UU.NET
(indirect): mayr@polya.stanford.edu
∂26-Sep-88 1838 misha@polya.Stanford.EDU This week's AFLB talk
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Sep 88 18:36:55 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA25408; Mon, 26 Sep 88 18:33:22 PDT
Date: Mon, 26 Sep 88 18:33:22 PDT
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8809270133.AA25408@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU, csd.aflb@polya.Stanford.EDU
Subject: This week's AFLB talk
The AFLB will (usually) meet, as before, on Thursdays,
at 12:30 pm. The first talk will be given in room 220,
Misha
subsequent talks will be in room 352, same as last year.
TITLE:
An algorithm for the recognition of greedily solvable
transportation problems.
SPEAKER:
Dr. Ron Shamir (School of Mathematics, Tel Aviv University)
ABSTRACT:
In this talk we address the following question: Given a matrix of
costs for the transportation problem, determine if there exists a
permutation of the problem's variables, such that the problem is
greedily solvable by that permutation for every possible supply and
demand vectors. If the answer is positive, find such permutation. We
say that a problem is "greedily solvable" by a permutation, if the
greedy algorithm which maximizes each variable in turn, according to the
ordering in that permutation, provides an optimal solution.
In 1963, Hoffman gave a necessary and sufficient condition which,
given the matrix and the permutation of the variables, verifies that
the matrix is greedily solvable by that ordering. (In that case the
permutation is called a Monge sequence.) Hoffman's condition, though,
did not answer the question raised above, since it required prior
knowledge of the permutation in order to verify that the condition
holds. Until now, the question of existence and the generation of
Monge sequences had to be approached separately for every family of
transportation problems.
We shall describe an efficient algorithm for the problem. The
algorithm uses Hoffman's condition, but it does not require prior
knowledge of the Monge sequence. Our algorithm also generates the
corresponding Monge sequence whenever it exists. This facilitates the
solution of every subsequent transportation problem with that cost
matrix in linear time.
The running time of our algorithm is better than that of the
best known algorithms for the transportation problem, and thus it can
also be used as a preliminary step towards solving such problems,
without an increase in the overall complexity.
(Joint work with N. Alon, S. Cosares and D. Hochbaum.)
∂27-Sep-88 0900 @Score.Stanford.EDU:tom@polya.Stanford.EDU Chilled water shut-down
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Sep 88 09:00:34 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 27 Sep 88 08:55:39-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA04833; Tue, 27 Sep 88 08:56:27 PDT
Date: Tue, 27 Sep 88 08:56:27 PDT
From: Tom Dienstbier <tom@polya.Stanford.EDU>
Message-Id: <8809271556.AA04833@polya.Stanford.EDU>
To: su-computers@score, staff@score, faculty@score
Cc: tom@polya.Stanford.EDU
Subject: Chilled water shut-down
Folks, again we have been notified that the chilled water will be shut down
through the folowing dates. Friday, September 30, 4:00PM thru Monday October 3,
8:00. This is to connect the utilites(chilled water) to the new pipe line
that we have seen being installed at Lomita Mall Project. As you probably
already know, chilled water is what cools the building and most importantly,
the computer room. All CSDCF computers will be shut-down during this time.
These include the following systems; SCORE, POLYA, SAIL, Labrea, Jeeves,
and all printers. Devices that will be kept running are basically TIPS,
Gateways and Data Comm equipment. I suspect machines will be going down
at around 2:00 or earlier, on friday for tape backup. The exact times will be
anounced on the particular systems..
If you have additional questions please contact me.
Tom
3-1767
∂27-Sep-88 0940 hayes.pa@Xerox.COM Re: reading list
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Sep 88 09:40:17 PDT
Received: from Xerox.COM by russell.Stanford.EDU (4.0/4.7); Tue, 27 Sep 88 09:40:05 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 27 SEP 88 09:31:18 PDT
Date: 27 Sep 88 09:30 PDT
From: hayes.pa@Xerox.COM
Subject: Re: reading list
In-Reply-To: Jon Barwise <barwise@russell.stanford.edu>'s message of Tue, 06 Sep
88 11:32:25 PDT
To: barwise@russell.stanford.edu
Cc: ssp-faculty@russell.stanford.edu
Message-Id: <880927-093118-5846@Xerox>
May be late, I just got back and saw the correspondence. Quick reactions: I
would suggest that Nilsson&Genesereth and Rumelhart&MCClelland are both too
technical for an introductory reading list, and that Pylyshyn is very heavy
reading going over stuff well covered , by and large, by Haugeland. How about a
collection of Fodor essays, or perhaps his "modular mind", which is unusually
readable ( for Fodor ) and has a nice literary appeal;, especially in its first
half, the historical essay on how phrenology wasnt completely insane. Shouldnt
there be something more explicitly linguistic, maybe not by Chomsky but enough
to motivate a concern with language issues, perhaps even a text of some kind?
∂27-Sep-88 1009 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Chilled water shut-down
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Sep 88 10:09:16 PDT
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 27 Sep 88 10:05:33-PDT
Message-ID: <1Wi8Te@SAIL.Stanford.EDU>
Date: 27 Sep 88 0945 PDT
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: Chilled water shut-down
To: tom@POLYA.Stanford.EDU
CC: faculty@SCORE.STANFORD.EDU
This is disasterous. Firstly, we have very little notice. And secondly,
it is more than the entire weekend during the first weekend of the
quarter. It would have been far better before the quarter started. Also,
they gave us several weeks notice the last time they shut off chilled
water. I believe a complaint is in order.
Arthur
∂27-Sep-88 1014 TAJNAI@Score.Stanford.EDU Re: Chilled water shut-down
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Sep 88 10:14:09 PDT
Date: Tue 27 Sep 88 10:08:56-PDT
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Re: Chilled water shut-down
To: ARK@Sail.Stanford.EDU, tom@Polya.Stanford.EDU
cc: faculty@Score.Stanford.EDU
In-Reply-To: <1Wi8Te@SAIL.Stanford.EDU>
Message-ID: <12433939375.17.TAJNAI@Score.Stanford.EDU>
I agree with Arthur. The timing is terrible.
Carolyn
-------
∂27-Sep-88 1201 @Score.Stanford.EDU:tom@polya.Stanford.EDU Chilled water shut-down
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Sep 88 12:01:11 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 27 Sep 88 11:57:33-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA19118; Tue, 27 Sep 88 11:58:11 PDT
Date: Tue, 27 Sep 88 11:58:11 PDT
From: Tom Dienstbier <tom@polya.Stanford.EDU>
Message-Id: <8809271858.AA19118@polya.Stanford.EDU>
To: ARK@SAIL.Stanford.EDU
Cc: faculty@SCORE.STANFORD.EDU
In-Reply-To: Arthur Keller's message of 27 Sep 88 0945 PDT <1Wi8Te@SAIL.Stanford.EDU>
Subject: Chilled water shut-down
I agree, a complaint has been lodged. I am working with the O&M folks trying
to get us an alternate source for cooling.
tom
∂27-Sep-88 1418 TAJNAI@Score.Stanford.EDU IBM PC needed for blind MSCS student
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Sep 88 14:18:11 PDT
Date: Tue 27 Sep 88 14:14:14-PDT
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: IBM PC needed for blind MSCS student
To: faculty@Score.Stanford.EDU
Message-ID: <12433984031.50.TAJNAI@Score.Stanford.EDU>
Does anyone have a spare IBM PC for a new CSMS student to use.
Gio Wiederhold has a DEC talk unit that will translate.
Carolyn
-------
∂27-Sep-88 1423 @Score.Stanford.EDU:ball@polya.Stanford.EDU Chilled water shut-down
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Sep 88 14:23:07 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 27 Sep 88 14:18:20-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA29060; Tue, 27 Sep 88 14:19:02 PDT
Date: Tue, 27 Sep 88 14:19:02 PDT
From: Jim Ball <ball@polya.Stanford.EDU>
Message-Id: <8809272119.AA29060@polya.Stanford.EDU>
To: ARK@SAIL.Stanford.EDU
Cc: tom@POLYA.Stanford.EDU, faculty@SCORE.STANFORD.EDU
In-Reply-To: Arthur Keller's message of 27 Sep 88 0945 PDT <1Wi8Te@SAIL.Stanford.EDU>
Subject: Chilled water shut-down
Arthur,
CSD-CF has been in daily contact with the engineering people, as we mentioned
at the Faculty Lunch. We have been complaining to them non-stop for about a
week. As Tom Dienstbier pointed out at the meeting they have agreed to hold
off on the shutdown unless they can provide some emergency chilled water
relief.
It might still be a good idea to ping them from the department.
-Jim
∂27-Sep-88 1438 GILBERTSON@Score.Stanford.EDU CSD Offices Close Thurs at 4
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Sep 88 14:38:12 PDT
Date: Tue 27 Sep 88 14:29:32-PDT
From: Edith Gilbertson <GILBERTSON@Score.Stanford.EDU>
Subject: CSD Offices Close Thurs at 4
To: CSD-List@Score.Stanford.EDU
cc: Gilbertson@Score.Stanford.EDU
Message-ID: <12433986816.34.GILBERTSON@Score.Stanford.EDU>
The Computer Science Department offices will close at 4:00 p.m. on
Thursday, September 29, for the CSD Reception.
All CSD students, faculty and staff are invited to the Autumn kick-off
which will be held on the Margaret Jacks Hall patio.
-------
∂27-Sep-88 1617 @Score.Stanford.EDU:rw@polya.Stanford.EDU CS Departmental Reception
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Sep 88 16:16:47 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 27 Sep 88 16:05:56-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA10735; Tue, 27 Sep 88 16:06:46 PDT
Date: Tue, 27 Sep 88 16:06:46 PDT
From: Rich Washington <rw@polya.Stanford.EDU>
Message-Id: <8809272306.AA10735@polya.Stanford.EDU>
To: csd-list@score
Subject: CS Departmental Reception
It's time once again to usher in the new academic year with an
appropriate attitude. To help establish that proper frame of
mind, we'll be holding the annual CSD feeding frenzy known as
the Departmental Reception this Thursday, September 29, at 4 PM,
on the ground floor courtyard between Margaret Jacks Hall and
the Psychology building.
The reception gives you a chance to welcome new students, to
meet other people in the department, and to see those people who
haven't emerged from in front of their terminal since last
year's reception.
To give you a break from eating, departmental awards will be
presented during the reception. In past years these have included
awards to students for teaching and service to the department.
At some point, a pick-up volleyball game will get underway out in
the Oval in front of the quad. Listen for the cry of "VOLLEYBALL"
that will cut through the din of the courtyard.
But of course, the central reason people come to the reception is
for the food and drink. We'll have lots of both (including beer
and wine to help you recover from the first couple days of classes).
This event happens only once a year, so be sure to be there!
∂27-Sep-88 1719 @Score.Stanford.EDU:tah@linz Getting in touch with the new students
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Sep 88 17:19:03 PDT
Received: from linz.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 27 Sep 88 17:14:40-PDT
Received: by linz.stanford.edu (4.0/SMI-DDN)
id AA06168; Tue, 27 Sep 88 17:14:52 PDT
Message-Id: <8809280014.AA06168@linz.stanford.edu>
To: faculty@score
Subject: Getting in touch with the new students
Date: 27 Sep 88 17:14:48 PDT (Tue)
From: Tom Henzinger <tah@linz>
The question of how to get in touch with the new students, and how to get
them interested and involved in your research, was raised at today's faculty
meeting.
I urge all of you who have regular research group meetings or seminars,
to post an announcement not only on csd@score but, with a special invitation
to the new PhD students, also on post-new-phd@polya, and maybe even send it
to all PhD students directly (phd@score).
--Tom.
∂28-Sep-88 0835 @Score.Stanford.EDU:tom@polya.Stanford.EDU Chilled Water Update
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Sep 88 08:35:03 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 28 Sep 88 08:30:46-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA14064; Wed, 28 Sep 88 08:31:39 PDT
Date: Wed, 28 Sep 88 08:31:39 PDT
From: Tom Dienstbier <tom@polya.Stanford.EDU>
Message-Id: <8809281531.AA14064@polya.Stanford.EDU>
To: faculty@score, csd@score, Staff@score
Subject: Chilled Water Update
After lengthly meeting yesterday afternoon, it has been decided that
the chilled water in Margaret Jacks, will not be shut down. Facilities
Project Office will provide an alternate source of cooling that will tie
into the existing system. This "alternate source" tie-in will be done
on the fly with no downtime on the chilled water utility. Also, the tie-in
to the pipes on Lomita Mall Project will not be done this weekend but
postponed until next weekend. No matter what happens, as part of the Mall
Facilities Project, we have quarantee that our service(cooling) will not
be interupted/hampered. Lets keep our fingers crossed that this all works
out as planned.
Tom Dienstbier
CSDCF
∂28-Sep-88 1118 helen@russell.Stanford.EDU SSP Lunch
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Sep 88 11:18:20 PDT
Received: by russell.Stanford.EDU (4.0/4.7); Wed, 28 Sep 88 11:17:50 PDT
Date: Wed 28 Sep 88 11:17:47-PDT
From: Helen Nissenbaum <HELEN@CSLI.Stanford.EDU>
Subject: SSP Lunch
To: ssp-faculty@russell.Stanford.EDU
Message-Id: <591473867.0.HELEN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
******** Symbolic Systems Program Lunch and Faculty Meeting ***********
When: Friday, October 21
Noon.
Where: Cordura Hall, Conference Room
Please mark this time on your calendars. This is the first faculty meeting
of the year (and probably the only one this quarter). There are important
decisions to be made regarding the programs policies and direction, and much
information that needs to be updated. I'll be sending out an agenda closer to
the time of the meeting.
The booklet is complete and about to go into print. Thanks very much to those
of you who gave us input.
Hope to see you at October's meeting.
Helen Nissenbaum
-------
∂28-Sep-88 1139 @Score.Stanford.EDU:RINDFLEISCH@SUMEX-AIM.Stanford.EDU Re: Facilities Committee Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Sep 88 11:38:25 PDT
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 28 Sep 88 11:34:25-PDT
Date: Wed, 28 Sep 88 11:11:55 PDT
From: TC Rindfleisch <Rindfleisch@SUMEX-AIM.Stanford.EDU>
Subject: Re: Facilities Committee Meeting
To: Facil@Score.Stanford.EDU
cc: Rindfleisch@SUMEX-AIM.Stanford.EDU, Faculty@Score.Stanford.EDU
In-Reply-To: <12432412938.27.RINDFLEISCH@SUMEX-AIM.Stanford.EDU>
Message-ID: <12434212986.27.RINDFLEISCH@SUMEX-AIM.Stanford.EDU>
OK, we should be set to hold the first meeting of the CSD Facilities Committee
this academic year on Tuesday, October 4, from 9:00 - 11:00 in MJH 252. The
agenda will be:
1) "State of CSD/CF" report:
- Technical status
- Fiscal status
- Staffing status and support commitments
- System loading/usage profiles, trends, and cost recovery patterns
2) Plans for this coming year:
- Network server/workstation upgrades and expansions
- Continued (cost-effective?) support of old systems (e.g., SAIL and SCORE)
- R&D projects on-going and planned (e.g., fiber optics networks?).
- Vendor relations and initiatives (DEC, SUN, Apple, NeXT, etc.)
- User charges and access policies.
3) Longer range plans for NWC.
4) General discussion.
Tom R.
-------
∂28-Sep-88 1326 LOGMTC-mailer MTC Seminar
Received: from linz.stanford.edu by SAIL.Stanford.EDU with TCP; 28 Sep 88 13:26:43 PDT
Received: by linz.stanford.edu (4.0/SMI-DDN)
id AA06913; Wed, 28 Sep 88 13:24:31 PDT
Message-Id: <8809282024.AA06913@linz.stanford.edu>
To: students@score
Cc: csd@score, post-new-phd@polya, logmtc@sail
Subject: MTC Seminar
Date: 28 Sep 88 13:24:28 PDT (Wed)
From: Tom Henzinger <tah@linz>
For all of you who are new here:
MTC
denotes Stanford's nutty (6,3)
"Mathematical Theory of Computation,"
which has nothing to do with combinatorics and hardly anything with
complexity theory, but rather encompasses all those areas of theoretical
computer science which use tools from mathematical logic and universal
algebra to tackle their problems.
MTC constitutes, together with AA (Analysis of Algorithms), "theory" at
Stanford's CS department. To counter AA's identification with STOC and
FOCS, MTC's scope is roughly identical with the topics represented at LICS
(Logic in Computer Science) and the more theoretical side of POPL
(Principles of Programming Languages). If you still don't know what we are
talking about, here are some buzzwords (stolen from the syllabus of the MTC
qualifying exam):
* Logic of programs, program verification, logic programming
* Programming language theory, denotational semantics, algebraic
semantics, type theories
* Concurrency modeling, theory of processes, temporal logic
* Automated deduction, program synthesis
We're going to have a weekly lunch-time, seminar-type meeting. It's not
quite clear yet what it will look like; only what we are not going to do
has been decided. At research-level talks, people in the audience either
know most of the stuff already or they tend to be lost after the first
five minutes; so we won't invite any speakers. The idea is rather that it
will be some sort of problem solving and discussion seminar with equal
participation of everybody (modeled, kind of, after Dijkstra's notorious
Tuesday afternoon clubs). Hence continuous and active attendance will be
essential for a successful seminar.
The meetings are, very much like AFLB, not associated with any particular
faculty member or research group, although John Mitchell has agreed to
take part. Students who are interested in MTC but do not have a thesis
topic yet are especially encouraged to participate.
The seminar is going to be staged every Friday at 12:00 noon in MJH 252.
The first, organizational meeting will be on Friday, October 7. It is then
when we will decide on the exact mode of the meetings and on the topics to
be covered, which will largely depend on the interests of the participants.
If you are interested, you should therefore try to attend this first meeting
next Friday.
If you want to be on the mailing list for future announcements, please send
me a note.
Tom
∂28-Sep-88 1456 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu request for paper
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Sep 88 14:56:11 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA17621; Wed, 28 Sep 88 14:54:07 PDT
Message-Id: <8809282154.AA17621@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 28 Sep 88 14:54:56 PDT
Received: by BYUADMIN (Mailer X1.25) id 7935; Wed, 28 Sep 88 15:52:40 MDT
Date: Wed, 28 Sep 88 12:33:13 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Ian Parberry <ian%PSUVAX1.CS.PSU.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Ian Parberry <ian%PSUVAX1.CS.PSU.EDU@Forsythe.Stanford.EDU>
Subject: request for paper
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Does anybody out there have a copy of Chung and Ravikumar's paper
"On the size of test sets for sorting and related problems"?
The only reference for it that I have is "submitted for publication",
which does not give a lot of information.
I have asked the authors to send me a copy at least 4 times
by mail and at least 5 times by telephone. I've lost track of
how long it has been, but it has been at least since February.
Ravikumar has solemnly promised to send me a copy "next week"
several times. My patience is wearing thin.
I have put off doing this as long as possible, but I can see no alternative.
Surely SOMEBODY must have a copy of this paper. If you have a copy
that you can send me, please reply by email.
Ian.
-------------------------------------------------------------------------------
Ian Parberry
ian@psuvax1.cs.psu.edu ian@psuvax1.BITNET ian@psuvax1.UUCP (814) 863-3600
Dept of Comp Sci, 333 Whitmore Lab, Penn State Univ, University Park, Pa 16802
∂28-Sep-88 1601 TAJNAI@Score.Stanford.EDU USWest Advanced Technologies sponsored research
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Sep 88 16:01:45 PDT
Date: Wed 28 Sep 88 15:56:04-PDT
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: USWest Advanced Technologies sponsored research
To: faculty@Score.Stanford.EDU
cc: hayes-roth@SUMEX-AIM.Stanford.EDU, engelmore@SUMEX-AIM.Stanford.EDU,
hiller@Score.Stanford.EDU
Message-ID: <12434264712.10.TAJNAI@Score.Stanford.EDU>
US WEST is announcing the third year of their sponsored research program.
Mr. Lewis House only sent one brochure, and if you are interested, I think
the best procedure is for you to call his office on 303/740-1570 and
request one.
Deadline for submission of intent to propose is 11/1/88
invitations to submit full proposal will go out 12/15/88
Compute proposals due 2/1/89
announcement of selected projects 3/31/89
june - September 1989 - Projects commence as soon as the
research contracts can be negotiated, or at
an agreed later date.
Funding levels range from $30K to around $200K
Desired Areas of research:
AI: Knowledge-based information systems, signal processing, natural language
Communiucation and Computing Systems Architecture: LAN/MAN Systems,
Distributed Technology, communication protocols, switching control
software, transport structure, modeling of cost/response
time reliability, distributed databases, security, heterogeneous system
operations.
Modeling & Simulation: General Combinatorial optimization methods,
applications of combinatorial optimization for network design,
stochastic network optimizer.
Software Productivity: software engineering systems,
specificiation languages, rapid prototyping technologies,
software maintenance and re-engineering
-------
∂28-Sep-88 1724 DELAGI@SUMEX-AIM.Stanford.EDU [Bob Sandstrom <sandstro@JUNE.CS.WASHINGTON.EDU>:]
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Sep 88 17:24:34 PDT
Date: Wed, 28 Sep 88 17:16:53 PDT
From: Bruce A. Delagi <DELAGI@SUMEX-AIM.Stanford.EDU>
Subject: [Bob Sandstrom <sandstro@JUNE.CS.WASHINGTON.EDU>:]
To: aap@SUMEX-AIM.Stanford.EDU
Message-ID: <12434279425.28.DELAGI@SUMEX-AIM.Stanford.EDU>
Return-Path: <fpst@HUBCAP.CLEMSON.EDU>
Received: from RELAY.CS.NET by SUMEX-AIM.Stanford.EDU with TCP; Mon, 26 Sep 88 05:48:49 PDT
Received: from hubcap.clemson.edu by RELAY.CS.NET id aa17749; 26 Sep 88 8:34 EDT
Received: by hubcap.clemson.edu; Mon, 26 Sep 88 08:28:36 edt
Date: Mon, 26 Sep 88 08:28:36 edt
Message-Id: <8809261228.AA15017@hubcap.clemson.edu>
To: DELAGI%SUMEX-AIM.Stanford.EDU@RELAY.CS.NET,
coraki!pratt%Sun.COM@RELAY.CS.NET, cvb%daresbury.ac.uk@RELAY.CS.NET,
develo%waikato.ac.nz@RELAY.CS.NET, dwk%cs.tufts.edu@RELAY.CS.NET,
gopalakr%enuxha.asu.edu@RELAY.CS.NET,
hcube-users%hamlet.caltech.edu@RELAY.CS.NET,
hcube-users%mtu.edu@RELAY.CS.NET,
mcdonaldi%comsci.ua.oz%uunet.UU.NET@RELAY.CS.NET,
prasanna%usc-cse.usc.edu@RELAY.CS.NET,
scherrer%lovada.dec.com@RELAY.CS.NET
Newsgroups: comp.parallel
From: Bob Sandstrom <sandstro@JUNE.CS.WASHINGTON.EDU>
Subject: A System for Object-Oriented Parallel Programming
Approved: parallel@hubcap.clemson.edu
PRESTO, an environment for writing object-oriented parallel programs
in the C++ programming language, is now available on the Internet.
PRESTO provides the programmer with a set of pre-defined object
types that simplify the construction of parallel programs.
PRESTO runs on Sequent Symmetry DYNIX 3.0 and VAX ULTRIX 2.0.
PRESTO is written in C++. We provide PRESTO source code, documentation,
and some simple programs written on top of PRESTO. You must provide
a C++ translator on your own.
The following should get you started. As usual, please try
to avoid the peak load hours of the computers and nets involved.
ftp june.cs.washington.edu (128.95.1.4)
anonymous
(your username)
cd pub
type binary
get presto.tar.Z
bye
ls -l presto.tar.Z (should be 213581 bytes)
sum presto.tar.Z (should be 15573 209)
uncompress presto.tar.Z
tar xvf presto.tar
You can read more about PRESTO in ACM SIGPLAN PPEALS (July 1988)
and Software -- Practice & Experience (August 1988).
Bob Sandstrom
Computer Science Laboratory
Department of Computer Science
University of Washington
sandstro@cs.washington.edu
-------
∂28-Sep-88 1725 DELAGI@SUMEX-AIM.Stanford.EDU
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Sep 88 17:25:44 PDT
Date: Wed, 28 Sep 88 17:17:27 PDT
From: Bruce A. Delagi <DELAGI@SUMEX-AIM.Stanford.EDU>
To: aap@SUMEX-AIM.Stanford.EDU
Message-ID: <12434279530.28.DELAGI@SUMEX-AIM.Stanford.EDU>
Return-Path: <fpst@HUBCAP.CLEMSON.EDU>
Received: from RELAY.CS.NET by SUMEX-AIM.Stanford.EDU with TCP; Mon, 26 Sep 88 05:50:08 PDT
Received: from hubcap.clemson.edu by RELAY.CS.NET id aa17768; 26 Sep 88 8:36 EDT
Received: by hubcap.clemson.edu; Mon, 26 Sep 88 08:30:29 edt
Date: Mon, 26 Sep 88 08:30:29 edt
Message-Id: <8809261230.AA15055@hubcap.clemson.edu>
To: DELAGI%SUMEX-AIM.Stanford.EDU@RELAY.CS.NET,
coraki!pratt%Sun.COM@RELAY.CS.NET, cvb%daresbury.ac.uk@RELAY.CS.NET,
develo%waikato.ac.nz@RELAY.CS.NET, dwk%cs.tufts.edu@RELAY.CS.NET,
gopalakr%enuxha.asu.edu@RELAY.CS.NET,
hcube-users%hamlet.caltech.edu@RELAY.CS.NET,
hcube-users%mtu.edu@RELAY.CS.NET,
mcdonaldi%comsci.ua.oz%uunet.UU.NET@RELAY.CS.NET,
prasanna%usc-cse.usc.edu@RELAY.CS.NET,
scherrer%lovada.dec.com@RELAY.CS.NET
Newsgroups: comp.parallel
Subject: Workshop on hypercubes
Keywords: hypercube, distributed computers, parallel architecture
Approved: parallel@hubcap.clemson.edu
CALL FOR PAPERS
1989 European workshop on hypercube and distributed computers
October 4-6,1989 --- RENNES, FRANCE
Program Chairman
J.P. Verjus
Organizing Committee
F. Andr\'e, & M. Cosnard, & P. Leca, & H. Leroy
B. Philippe, & T. Priol, & P. Quinton, & Y. Robert
Program Committee
F. Andr'e (IRISA - France) C. Addison (CMI - Norway)
L. Beermaert (UCL - Belgium) T. Bemmerl (TUMII - W. Germany)
R. Chamberlain (INTEL - England) M. Cosnard (ENS-Lyon - France)
R. Hempel (GMD - W. Germany) B. Kagstrom (U. of Umea - Sweden)
P. Leca (ONERA - France) H. Leroy (IRISA - France)
A. Lichnewski (INRIA - France) B. Philippe (IRISA - France)
T. Priol (IRISA - France) P. Quinton (IRISA - France)
Y. Robert (INPG - France) D. Roose (UCL - Belgium)
K. Solchenbach (SUPRENUM - W. Germany) U. Trottenberg (SUPRENUM - W. Germany)
M. Valero (UPC - Spain) J.P. Verjus (INPG - France)
Purpose
The workshop will cover applications experiences and original research
results in distributed computing on hypercube and compatible computers.
Acceptable topics include (but are not limited to) algorithms, architectures,
performance evaluation and applications.
Date and place
The conference will be held in Rennes (France), October 4 to October 6, 1989.
Papers
Full papers (20 will be accepted) : Authors are invited to submit four copies
of their contribution in its final form. Full papers are restricted to 15
pages and are due February 15, 1989. Short contribution (10 will be
accepted): Authors are invited to submit four copies of their abstract for
February 15, 1989. All accepted full papers will appear in a hardbound volume.
Authors will be notified of acceptance or rejection by April 15, 1989.
Papers and abstract should be sent to:
* F. Andre
IRISA
Campus de Beaulieu
Avenue du general Leclerc
35042 Rennes cedex
FRANCE
Organization
Attendance is restricted to 200 participants.
Host institution : IRISA, Rennes, France.
Sponsorized by : INRIA.
-------
∂28-Sep-88 1748 emma@csli.Stanford.EDU CSLI Calendar, September 29, 4:2
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Sep 88 17:48:37 PDT
Received: by csli.Stanford.EDU (4.0/4.7); Wed, 28 Sep 88 16:58:35 PDT
Date: Wed, 28 Sep 88 16:58:35 PDT
From: emma@csli.Stanford.EDU (Emma Pease)
To: friends@csli.Stanford.EDU
Subject: CSLI Calendar, September 29, 4:2
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
29 September 1988 Stanford Vol. 4, No. 2
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR NEXT THURSDAY, 29 September 1988
12 noon TINLecture
Cordura Hall Stage-level and Individual-level Predicates
Conference Room by Angelica Kratzer
UMass Linguistics Department
2:15 p.m. CSLI Seminar
Cordura Hall Resolution: An Overview of the Problem
Conference Room Ivan Sag
(sag@csli.stanford.edu)
See below
3:45 p.m. Tea
Ventura Hall
4:00 p.m. STASS Seminar
Cordura Hall Counterfactual Reasoning
Conference Room by Angelica Kratzer
UMass Linguistics Department
____________
CSLI ACTIVITIES FOR NEXT THURSDAY, 6 October 1988
12 noon TINLab
Cordura Hall What is Unification Grammar?
Conference Room Martin Kay
(Kay.pa@xerox.com)
Abstract below
2:15 p.m. CSLI Seminar
Cordura Hall Resolution: Some Approaches to the Problem
Conference Room Ivan Sag
(sag@csli.stanford.edu)
3:45 p.m. Tea
Ventura Hall
--------------
CSLI SEMINAR
Thursdays, 2:15-3:45
CSLI Seminars will focus each quarter on a particular issue or
problem. CSLI researchers and others will discuss the bearing their
work has on the issue.
The fall quarter seminar is being organized by Ivan Sag, Herb
Clark, and Jerry Hobbs; the issue is: The Resolution Problem for
Natural-Language Processing. How can communication proceed in light
of the fact that interpretation is radically underdetermined by
linguistic meaning?
Languages exhibit massive ambiguity:
I forgot how good beer tastes. [Structural ambiguity]
The pen is empty. [Lexical ambiguity]
Dukakis agrees to only three debates. [Scope ambiguity]
I saw her duck. [Lexical and structural ambiguity]
Kim likes Sandy more than Lou. [Ellipsis ambiguity]
And massive parametricity (expressions whose interpretation relies in
part on contextually fixed parameters):
He is crazy. (Who's he?)
John is in charge. (John who? In charge of what?)
She ran home afterwards. (After what?)
The nail is in the bowl. (Which nail? Nailed into the bowl, or just
inside of it?)
She cut the lawn/hair/cocaine/record. (What kind of cutting?)
John's book. (The book he owns?/wrote?/edited?)
The Resolution Problem for natural language is the question of how
diverse kinds of knowledge (e.g., knowledge of local domains, context
of utterance, the plans and goals of interlocutors, and knowledge of
the world at large) interact with linguistic knowledge to make
communication possible, even efficient. In this seminar, which will
include presentations by the instructors, by Michael Tanenhaus
(University of Rochester), and by David Rumelhart, we attempt to
clarify the nature of the Resolution Problem and to consider a
diversity of approaches toward a solution.
This course is listed as Linguistics 232, Psychology 229, and
Computer Science 379 and may be taken for 1-3 units by registered
Stanford students.
--------------
NEXT WEEK'S CSLI TINLAB
What is Unification?
Martin Kay
(kay.pa@xerox.com)
October 6
Unification is an operation on a pair of objects---usually expressions
in a formal language---that yields a new object of the same kind. It
comes up in logic, programming, and in several theories of
linguistics. In particular, it comes up in the kinds of linguistic
theories that are most often incorporated in computer programs. This
is not because it makes for obviously "procedural" theories---quite
the contrary. Why, then, does it appeal so strongly to
computationalists?
I will try to answer this question after first attempting to convey
the basic intuition behind unification.
______________
NOTE
Cordura Hall is our new building where we now hold our Thursday
events. It is on the corner of Panama Street and Campus Drive, next
to Ventura Hall, on the west side of the Campus.
∂28-Sep-88 2240 LOGMTC-mailer Logic seminar
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Sep 88 22:40:31 PDT
Received: by csli.Stanford.EDU (4.0/4.7); Wed, 28 Sep 88 22:40:29 PDT
Date: Wed 28 Sep 88 22:40:28-PDT
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: Logic seminar
To: Logic@csli.Stanford.EDU
Message-Id: <591514828.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Seminar in Logic and the Foundations of Mathematics
The topic for this quarter will be constructive and recursive mathematics
and relations with computation. I will begin with some background
lectures.
S. Feferman
First meeting: Mon., Oct.3, 4:15-5:30, Room 381-T, Stanford.
-------
∂29-Sep-88 0657 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Sep 88 06:55:25 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA23995; Thu, 29 Sep 88 08:27:49 PDT
Message-Id: <8809291527.AA23995@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 29 Sep 88 08:28:40 PDT
Received: by BYUADMIN (Mailer X1.25) id 9467; Thu, 29 Sep 88 09:26:28 MDT
Date: Thu, 29 Sep 88 09:58:05 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Date: 26 Sep 88 15:49:15 GMT
From: milos@cs.ucla.edu (Dr Milos Ercegovac)
Message-ID: <485@mcmi.UUCP>
Subject: 9th Symposium on Computer Arithmetic, 1989
-------------------------------------------------------------------------
9th SYMPOSIUM ON COMPUTER ARITHMETIC - ARITH 9
September 6-8, 1989
Santa Monica, California
Loews Santa Monica Beach Hotel
Sponsored by the Technical Committee on Computer Architecture (TCCA)
IEEE Computer Society
in cooperation with IFIP WG 2.5 and UCLA Computer Science Department
CALL FOR PAPERS
Authors are invited to submit papers describing new theoretical
and applied results on all aspects of computer arithmetic, in-
cluding but not restricted to the following topics:
+ Mathematical Foundations of Computer Arithmetic
+ Arithmetic Algorithms: Analysis, Implementation,
and Design Methodologies/Tools
+ Arithmetic Processor Architectures and Implementations
+ Design of Testable and Dependable Arithmetic Systems
+ Arithmetic Aspects in Application Areas such as Signal and
Image Processing, Graphics, and Robotics.
+ Numerical Error Control and Error Analysis
+ High Level Language Support of Arithmetic Systems
Four (4) copies of the complete paper (in English, not
exceeding 20 double-spaced typed pages) should be submitted to
Prof. Milos D. Ercegovac, Program Co-Chair, no later than Febru-
ary 1, 1989. Author(s) identification should only appear on a
separate sheet. Authors will be notified of acceptance by April
1, 1989, and final camera ready papers (up to 8 pages) will be
due May 1, 1989. Proceedings will be available at the symposium.
General Chairman Program Co-Chairman Program Co-Cha
Prof. Algirdas Avizienis Prof. Milos D. Ercegovac Dr. Earl Swartz
Computer Science Department Computer Science Department Defense Systems Group
4731G Boelter Hall 3732C Boelter Hall Bldg. R2/2076
UCLA UCLA TRW
Los Angeles, Los Angeles, Redondo Beach,
CA 90024 CA 90024 CA90278
213/825-3028 213/825-5414 213/812-0791
aviz@cs.ucla.edu milos@cs.ucla.edu
∂29-Sep-88 0708 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu 1989 STOC call for papers
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Sep 88 07:07:54 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA24373; Thu, 29 Sep 88 08:40:07 PDT
Message-Id: <8809291540.AA24373@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 29 Sep 88 08:40:59 PDT
Received: by BYUADMIN (Mailer X1.25) id 9672; Thu, 29 Sep 88 09:37:47 MDT
Date: Thu, 29 Sep 88 10:00:30 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Christos Papadimitriou <christos%HELOIS.UCSD.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Christos Papadimitriou <christos%HELOIS.UCSD.EDU@Forsythe.Stanford.EDU>
Subject: 1989 STOC call for papers
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
CALL FOR PAPERS
1989 ACM SYMPOSIUM ON THE THEORY OF COMPUTING
The Twenty First Annual ACM Symposium on Theory of Computing, sponsored
by the ACM Special Interest Group for Automata and Computability Theory
(SIGACT), will be held in Seattle, in the state of Washington, May 14-16, 1989.
Papers presenting original research on theoretical aspects of Computer Science
are sought. Typical, but not exclusive, topics of interest include:
Algorithms and data structures, logics of programs, computability and
complexity, parallel and distributed computation, computational geometry,
robotics, cryptography, semantics of programming languages, database theory,
and formal aspects of VLSI and layout.
SUBMISSION OF ABSTRACTS: Authors are requested to send twelve copies of a
detailed abstract (not a full paper) by Nov. 14, 1988 to:
Christos H. Papadimitriou
Dept. of Computer Science and Engineering, C-014
University of California at San Diego
La Jolla, California 92093
Abstracts should contain sufficient detail, as well as references to and
comparisons with relevant extant work, to enable program committee members to
appreciate their merits. It is recommended that abstracts start with a
succinct statement of the problem and discussion of its significance and
relevance to computation, appropriate for a non-specialist reader. A
technical exposition, directed to the specialist, should follow. A limit of
10 double-spaced pages (about 12,000 bytes) is placed on all abstracts.
Abstracts that significantly deviate from these guidelines risk rejection
without consideration of their merits. Abstracts not received by the Nov. 14
deadline (and not mailed by air, postmarked before Nov. 7)
**will not be considered**.
The program committee consists of Fan Chung, Cynthia Dwork, Faith Fich,
Shafi Goldwasser, Debbie Joseph, Maria Klawe, Nancy Lynch, Christos
Papadimitriou, Vijaya Ramachandran, 'Eva Tardos, Avi Wigderson, and Frances Yao.
Authors will be notified of acceptance or rejection by Jan. 20, 1989.
A copy of each accepted paper is required by March 6, 1989.
These copies may be either on special forms (model pages), which will
be sent to the authors, or typeset as reduced-size (8 1/2 X 11)
model pages. Authors who do not need the model pages are requested to
make note of that fact in the letter of submittal.
Information about local arrangements can be obtained from the conference
chairman:
Richard E. Ladner
Department of Computer Science, FR53
University of Washington
Seattle, Washington 98195
∂29-Sep-88 1544 X3J13-mailer Fairfax attendees
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Sep 88 15:43:19 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00246g; Thu, 29 Sep 88 14:41:12 PST
Received: by challenger id AA00805g; Thu, 29 Sep 88 15:38:54 PDT
Date: Thu, 29 Sep 88 15:38:54 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809292238.AA00805@challenger>
To: x3j13@sail.stanford.edu
Subject: Fairfax attendees
Thus far:
X3J13 Attendee Information
09/23/88
Name Institute Paid L1 L2
Jim Antonisse The MITRE Corporation - y -
Kim Barrett USC - - -
David Bartley TI y y y
Paul Beiser HP - y y
Danny Bobrow Xerox y y y
Skona Brittian MSC y y y
Kathy Chapman Digital Equipment Corporation - - -
Jeff Dalton University of Edinburgh - y y
Jerry Duggan HP - y y
Dick Gabriel Lucid, Inc. - y y
David Gray TI y y y
George Hadden Honeywell Systems \& Research - y y
Gregor Kiczales Xerox PARC - y y
Timothy Koschmann Southern Illinois University y y y
Aaron Larson Honeywell - y y
Thom Linden IBM y y y
David Loeffler MCC - y y
Sandra Loosemore Evans & Sutherland - y y
Barry Margolin Thinking Machines - y y
Larry Masinter Xerox PARC y y y
Bob Mathis Contel - y y
Crispin Perdue Sun Microsystems - y y
Dan Pierson Encore - y y
Kent Pitman Symbolics - y y
Rick Tucker Mitre Corporation - y y
David Unietis Lucid, Inc. - y y
Mary Van Deusen IBM Research y y y
Walter van Roggen Digital Equipment Corporation - y -
Ellen Waldrum TI - y y
JonL White Lucid, Inc. - y y
Jan Zubkoff Lucid, Inc. - y y
∂29-Sep-88 1546 X3J13-mailer Fairfax Subcommittee Meetings Update
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Sep 88 15:46:06 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00255g; Thu, 29 Sep 88 14:44:00 PST
Received: by challenger id AA00811g; Thu, 29 Sep 88 15:41:40 PDT
Date: Thu, 29 Sep 88 15:41:40 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809292241.AA00811@challenger>
To: x3j13@sail.stanford.edu
Subject: Fairfax Subcommittee Meetings Update
Subcommittee meetings
October 10, 1988
9:30 - 5:00 Characters (4-5)
9:30 - 12:30 Cleanup (?)
12:30 - 4:30 Editorial
2:00 - 5:00 Compiler (12)
2:30 - 5:00 Iteration (4)
∂29-Sep-88 1544 X3J13-mailer Fairfax Updated Agenda DRAFT
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Sep 88 15:44:29 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00252g; Thu, 29 Sep 88 14:42:24 PST
Received: by challenger id AA00808g; Thu, 29 Sep 88 15:40:06 PDT
Date: Thu, 29 Sep 88 15:40:06 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809292240.AA00808@challenger>
To: x3j13@sail.stanford.edu
Subject: Fairfax Updated Agenda DRAFT
**************DRAFT**************
X3J13 Committee Meeting Agenda
October 11 - 12, 1988
1 Call to Order, October 11, 9:00am
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Character Subcommittee Report and Vote, Thom Linden (3 hrs)
6 Lunch, 12:00pm - 1:00pm
7 CLOS Workshop Report, Danny Bobrow (20 minutes)
8 CLOS Chapter 3, Gregor Kiczales (20 minutes)
9 Compiler Subcommittee Report and Vote, Sandra Loosemore (2 hrs)
10 Editorial Subcommittee Report, Kathy Chapman (30 minutes)
11 Recess, 5:00pm
12 Call to Order, October 12, 9:00am
13 Clean-up, Larry Masinter
14 Lunch, 12:00pm - 1:00pm
15 Error Terminology, Dan Pierson (30 minutes)
16 Registry for Packages, Modules, Features, Larry Masinter
17 Public-ftp access, Larry Masinter
18 Other committee reports
19 Adjournment, 5:00pm
∂29-Sep-88 1825 X3J13-mailer Re: Fairfax Updated Agenda DRAFT
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Sep 88 18:25:06 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 SEP 88 18:16:24 PDT
Date: 29 Sep 88 18:16 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Fairfax Updated Agenda DRAFT
In-reply-to: Jan Zubkoff <jlz@lucid.com>'s message of Thu, 29 Sep 88
15:40:06 PDT
To: Jan Zubkoff <jlz@lucid.com>
cc: x3j13@sail.stanford.edu
Message-ID: <880929-181624-1531@Xerox>
The two other topics I wanted to discuss -- registry for packages, modules,
features, and public-ftp access for public Common Lisp programs, I thought
would only take about 30 minutes, mainly just to organize something.
∂29-Sep-88 2154 hoffman@csli.Stanford.EDU about the Symbolic Systems Forum
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Sep 88 21:54:46 PDT
Received: by csli.Stanford.EDU (4.0/4.7); Thu, 29 Sep 88 21:54:06 PDT
Date: Thu 29 Sep 88 21:54:05-PDT
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: about the Symbolic Systems Forum
To: ssp-faculty@csli.Stanford.EDU, ssp-students@csli.Stanford.EDU,
ssp-forum@csli.Stanford.EDU
Message-Id: <591598445.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
The Symbolic Systems Forum hosts talks and presentations on any
subject even tangentially related to Symbolic Systems: subjects ranging from
neurophysiology, to various theoretical aspects of computation, to
philosophical perspectives on the mind and knowledge, to cognitive psychology,
to linguistics and to semiotics. The motivation behind the forum is two-fold.
First, the Forum seeks to bring together some unifying picture of the
similarities and disimilarities of the work in these disparate fields: it seeks
to build the grand unifying picture underlying the technical work in the field.
Second, the Forum attempts to raise various issues for discussion and to
encourage the exchange of ideas between faculty and students. Ideally, as each
student and faculty member brings to the forum their particular experience and
particular field of study, the discussions at the Forum will give rise to new
ideas. To participate, either declare SSP as a major or send your name and
e-mail address to hoffman@csli via e-mail to be put on the mailing list.
-------
∂29-Sep-88 2158 hoffman@csli.Stanford.EDU Institutionalizing the Forum
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Sep 88 21:58:31 PDT
Received: by csli.Stanford.EDU (4.0/4.7); Thu, 29 Sep 88 21:58:03 PDT
Date: Thu 29 Sep 88 21:58:02-PDT
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: Institutionalizing the Forum
To: ssp-faculty@csli.Stanford.EDU, ssp-students@csli.Stanford.EDU,
ssp-forum@csli.Stanford.EDU
Message-Id: <591598682.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
The opportunity which you have all been waiting for! Given that
last Spring's SSP Forum went well, we can probably count on the
continuing success of the Forum. So, we will begin to make more
of a substantial effort in good production of forums and opportunities
for majors to become involved in this production. In other words,
we will institutionalize the forum so that it will continue.
Currently, I envision a committee of 3 plus a chairman who has
ultimate responsibility and (thus) say. The committee will somehow
(perhaps alternating posts or different positions) divide labor
among the following concerns: budget and finance, entertainment
(social events, t-shirts, etc.), scheduling the forum (getting
speakers, thank you notes, etc.), and others which I may not have
thought of. (Please suggest.) Election of officers will be done
by consensus of the chairman, the program coordinator, and the
department chair (unless, again, a better suggestion.) As we are
required to have a constitution (for ASSU funding), we might work out
something simple along those lines. I wish to streamline all
bureaucracy and avoid it.
-------
∂29-Sep-88 2159 hoffman@csli.Stanford.EDU Advance Forum Timetable
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Sep 88 21:58:58 PDT
Received: by csli.Stanford.EDU (4.0/4.7); Thu, 29 Sep 88 21:58:31 PDT
Date: Thu 29 Sep 88 21:58:30-PDT
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: Advance Forum Timetable
To: ssp-faculty@csli.Stanford.EDU, ssp-students@csli.Stanford.EDU,
ssp-forum@csli.Stanford.EDU
Message-Id: <591598710.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
For those with busy calenders, I will put out the next couple
of weeks forums in brief without the abstracts. (The abstracts
have yet to arrive.) If you can, please attend. The Forum will
only survive if it proves to be well-attended. If there is a
reason why you cannot attend, which I might be able to do something
about, please let me know.
Oct 7: Meeting to discuss the SSP Forum, talk about the various
set-ups by which one might become involved, policy decisions,
discussion of issues which might be raised as forum issues, etc.
Basically a free-for-all discussion. One of the very crucial issues
to be discussed will be whether to forum is once per week or once per
two weeks.
Oct. 14: Professor Ivan Sag on Linguistics and SSP
Oct. 21: Professor John McCarthy on Formalizing Common Sense Knowledge
and Reasoning in Mathematical Logic
Oct. 28: Professor Solomon Feferman on Turing's Oracle.
Nov. 4: Last summer's crop of Symbolic Systems Interns and what they did
(tentative)
-------
∂30-Sep-88 0945 TAJNAI@Score.Stanford.EDU Student speakers for 1989 Forum meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Sep 88 09:45:19 PDT
Date: Fri 30 Sep 88 09:41:37-PDT
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Student speakers for 1989 Forum meeting
To: faculty@Score.Stanford.EDU
cc: hiller@Score.Stanford.EDU
Message-ID: <12434720836.17.TAJNAI@Score.Stanford.EDU>
This is an advance notice asking that you give thought to the students
you want to speak at the upcoming Forum meeting scheduled for Feb. 15/16.
I will be in Japan/Korea (and 5 days vacation in Hawaii) and will not
return to the office until Wednesday, October 26.
When I return, I will send you a message requesting nominations for
speakers.
First choice: PHD students who have not spoken and who will
graduate before the 1990 meeting.
Second choice: senior level PHD students who have important research to
present.
Jeff Eppinger and Monica Lam, our new faculty members, are invited to speak.
Also, faculty members may wish to present their work.
Ed Feigenbaum is the program chairman, and Nanni De Micheli
is the poster session chairman.
Carolyn Tajnai
-------
∂30-Sep-88 0956 X3J13-mailer Fairfax attendees
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 30 Sep 88 09:55:45 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Fri, 30 Sep 88 12:44:03 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 30 Sep 88 12:52:50 EDT
Date: Fri, 30 Sep 88 12:53 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Fairfax attendees
To: Jan Zubkoff <jlz@lucid.com>
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8809292238.AA00805@challenger>
Message-Id: <19880930165324.8.BARMAR@OCCAM.THINK.COM>
Date: Thu, 29 Sep 88 15:38:54 PDT
From: Jan Zubkoff <jlz@lucid.com>
Thus far:
X3J13 Attendee Information
09/23/88
Name Institute Paid L1 L2
Barry Margolin Thinking Machines - y y
I had our purchasing department send you a check with the registration
form. Did you receive the registration form without a check?
barmar
∂30-Sep-88 1236 X3J13-mailer March '89 X3J13/ISO meeting host needed
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 30 Sep 88 12:36:18 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00792g; Fri, 30 Sep 88 11:34:12 PST
Received: by challenger id AA01696g; Fri, 30 Sep 88 12:31:53 PDT
Date: Fri, 30 Sep 88 12:31:53 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809301931.AA01696@challenger>
To: x3j13@sail.stanford.edu
Subject: March '89 X3J13/ISO meeting host needed
I need a volunteer from the Boston area to host the X3J13 meeting March 27 -
29 and the ISO meeting March 30 - 31. Please let me know if you're
interested.
---jan---
∂30-Sep-88 1340 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu International Conference on Principal of Knowledge Representation
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Sep 88 13:40:17 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA10660; Fri, 30 Sep 88 13:38:08 PDT
Message-Id: <8809302038.AA10660@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 30 Sep 88 13:38:56 PDT
Received: by BYUADMIN (Mailer X1.25) id 0840; Fri, 30 Sep 88 14:35:45 MDT
Date: Fri, 30 Sep 88 15:08:58 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Yoav Shoham <SHOHAM@SCORE.STANFORD.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Yoav Shoham <SHOHAM@SCORE.STANFORD.EDU>
Subject: International Conference on Principal of Knowledge Representation
and R
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
The first international conference on principles of knowledge
representation and reasoning will take place on May 15-18, 1989,
in Toronto. It is geared towards the more rigorous areas of AI.
The intention is that the number of participants be somewhere
between the few dozens of a workshop and the masses of IJCAI, say
500. This is a good opportunity to widen the bridge between AI and
theory, and contributions from the theory community are solicited.
Please note the early sumbission deadline.
Yoav Shoham
Stanford University
Appendix:
>>
>> CALL FOR PAPERS
>>
>> FIRST INTERNATIONAL CONFERENCE ON
>> PRINCIPLES OF KNOWLEDGE REPRESENTATION AND REASONING
>>
>> Royal York Hotel
>> Toronto, Ontario, CANADA
>> May 15-18, 1989
>>
>> Sponsored by the Canadian Society for Computational Studies of Intelligence
>> -- With support from AAAI, IJCAI, the Canadian Institute for Advanced
>> Research, and the Information Technology Research Centre of Ontario
>> -- In cooperation with AISB[, and ACM SIGART]
>>
>>
>> The idea of explicit representations of knowledge, manipulated by
>> general-purpose inference algorithms, underlies much of the work in
>> artificial intelligence, from natural language to expert systems. A growing
>> number of researchers are interested in the principles governing systems
>> based on this idea. This conference will bring together these researchers in
>> a more intimate setting than that of the general AI conferences. In
>> particular, all authors will be expected to appear and give presentations of
>> adequate length to present substantial results. Accepted papers will be
>> collected in a conference proceedings, to be published by Morgan Kaufmann
>> Publishers, Inc.
>>
>> The conference will focus on principles of commonsense reasoning and
>> representation, as distinct from concerns of engineering and details of
>> implementation. Thus of direct interest are logical specifications of
>> reasoning behaviors, comparative analyses of competing algorithms and
>> theories, and analyses of the correctness and/or the computational complexity
>> of reasoning algorithms. Papers that attempt to move away from or refute the
>> knowledge-based paradigm in a principled way are also welcome, so long as
>> appropriate connections are made to the central body of work in the field.
>>
>>
>> Submissions are encouraged in at least the following topic areas:
>>
>>
>> Analogical Reasoning Qualitative Reasoning
>> Commonsense Reasoning Temporal Reasoning
>> Deductive Reasoning Planning
>> Diagnostic and Knowledge Representation Formalisms
>> Abductive Reasoning Theories of the Commonsense World
>> Evidential Reasoning Theories of Knowledge and Belief
>> Inductive Reasoning Belief Management and Revision
>> Nonmonotonic Reasoning Formal Task and Domain Specifications
>>
>>
>>
>>
>>
>> REVIEW OF PAPERS
>>
>>
>> The Program Committee will review extended abstracts (not complete papers).
>> Each submission will be read by at least two members of the Committee and
>> judged on clarity, significance, and originality. An important criterion for
>> acceptance of a paper is that it clearly contribute to principles of
>> representation and reasoning that are likely to influence current and future
>> AI practice.
>>
>> Extended abstracts should contain enough information to enable the Program
>> Committee to identify the principal contribution of the research and its
>> importance. It should also be clear from the extended abstract how the work
>> compares to related work in the field. References to relevant literature mus
t
>> be included.
>>
>> Submitted papers must never have been published. Submissions must also be
>> substantively different from papers currently under review and must not be
>> submitted elsewhere before the author notification date (December 15, 1988).
>>
>>
>> SUBMISSION OF PAPERS
>>
>> Submitted abstracts must be at most eight (8) double-spaced pages. All
>> abstracts must be submitted on 8-1/2" x 11" paper (or alternatively, a4),
>> and typed in 12-point font (pica on standard typewriter). Dot matrix
>> printout is not acceptable.
>>
>> Each submission should include the names and complete addresses of all
>> authors. Also, authors should indicate under the title which of the
>> topic ares listed above best describes their paper (if none is
>> appropriate, please give a set of keywords that best describe the
>> topic of the paper).
>>
>> Abstracts must be received no later than November 1, 1988, at the address
>> listed immediately below. Authors will be notified of the Program Committee'
s
>> decision by December 15, 1988. Final camera-ready copies of the full papers
>> will be due a short time later, on February 15, 1989. Final papers will be a
t
>> most twelve (12) double-column pages in the conference proceedings.
>>
>>
>> Send five (5) copies of extended abstracts [one copy is acceptable from
>> countries where access to copiers is limited] to
>>
>> Ron Brachman and Hector Levesque, Program Co-chairs
>> First International Conference on Principles of
>> Knowledge Representation and Reasoning
>> c/o AT&T Bell Laboratories
>> 600 Mountain Avenue, Room 3C-439
>> Murray Hill, NJ 07974
>> USA
>>
>>
>>
>> Inquiries of a general nature can be addressed to the Conference Chair:
>>
>> Raymond Reiter, Conference Chair
>> First International Conference on Principles of
>> Knowledge Representation and Reasoning
>> c/o Department of Computer Science
>> University of Toronto
>> 10 Kings College Road
>> Toronto, Ontario M5S 1A4
>> CANADA
>>
>> electronic mail: reiter@ai.toronto.edu
>>
>>
>>
>>
>> IMPORTANT DATES
>>
>> Submission deadline: November 1, 1988
>> Author notification date: December 15, 1988
>> Camera-ready copy due
>> to publisher: February 15, 1989
>> Conference: May 15-18, 1989
>>
>>
>>
>>
>>
>>
>>
>> PROGRAM COMMITTEE
>>
>> James Allen (University of Rochester)
>> Giuseppe Attardi (Delphi SpA, Italy)
>> Woody Bledsoe (MCC/University of Texas)
>> Alan Bundy (Edinburgh University)
>> Eugene Charniak (Brown University)
>> Veronica Dahl (Simon Fraser University)
>> Koichi Furukawa (ICOT)
>> Johan de Kleer (Xerox PARC)
>> Herve Gallaire (European Computer Industry Research Center, Munich)
>> Michael Genesereth (Stanford University)
>> Michael Georgeff (SRI International)
>> Pat Hayes (Xerox PARC)
>> Geoff Hinton (University of Toronto)
>> Bob Kowalski (Imperial College)
>> Vladimir Lifschitz (Stanford University)
>> Alan Mackworth (University of British Columbia)
>> Drew McDermott (Yale University)
>> Tom Mitchell (Carnegie-Mellon University)
>> Robert Moore (SRI International)
>> Judea Pearl (UCLA)
>> Stan Rosenschein (SRI International)
>> Stuart Shapiro (SUNY at Buffalo)
>> Yoav Shoham (Stanford University)
>> William Woods (Applied Expert Systems)
>>
>>
-------
∂30-Sep-88 1405 X3J13-mailer Arpanet access during Fairfax meeting
Received: from hqda-ai.ARPA by SAIL.Stanford.EDU with TCP; 30 Sep 88 14:05:48 PDT
Received: by hqda-ai.ARPA; Fri Sep 30 16:43:12 1988
From: Bill Arbaugh <arbaugh@hqda-ai.ARPA>
Message-Id: <8809302043.AA02302@hqda-ai.ARPA>
To: x3j13@sail.stanford.edu
Date: Fri, 30 Sep 88 16:43:10 EDT
Subject: Arpanet access during Fairfax meeting
X-Mailer: Elm [version 1.5b]
If you do not have a TAC card and would like to have access
to the arpanet for mail and etc., contact me directly and I can
help.
Bill
==========================================================
Bill Arbaugh Phone: (202) 694-6912
UUCP: *!uunet!cos!hqda-ai!arbaugh ARPA: arbaugh@hqda-ai.arpa
==========================================================
∂30-Sep-88 1416 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu PROFESSORSHIPS AVAILABLE IN ITALY
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Sep 88 14:16:03 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA13151; Fri, 30 Sep 88 14:14:11 PDT
Message-Id: <8809302114.AA13151@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 30 Sep 88 14:12:05 PDT
Received: by BYUADMIN (Mailer X1.25) id 1659; Fri, 30 Sep 88 15:09:55 MDT
Date: Fri, 30 Sep 88 16:01:59 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Ian Mason <iam%LFCS.EDINBURGH.AC.UK@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Ian Mason <iam%LFCS.EDINBURGH.AC.UK@Forsythe.Stanford.EDU>
Subject: PROFESSORSHIPS AVAILABLE IN ITALY
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
PROFESSORSHIPS AVAILABLE IN ITALY
33 positions as full professor are available in 18 different
Universities in Italy, in Computer Science.
There is no nationality nor language limitation.
The competition is handled nationally by a committee which will be
appointed by the Ministry of Education and is only based on Curricula
Vitae (resumes).
Anybody interested may ask for further information and application forms from
Mariangiola Dezani or Simona Ronchi
Telephone: 39 11 7712002
Email: Dezani@itoinfo.bitnet
Postal:
Departimento de Informatica
Corso Svizzera 185
Turin
Italy
In order to complete the application one may need some help by an italian
speaking person (the signature of a notary, certifying the identity
of the candidate, must be notarized (!) at an Italian Consulate).
The deadline is NOVEMBER 5.
As bureaucracy is slow, the procedure may take a couple of years, or
more, before one can actually start teaching.
Mariangiola Dezani
∂01-Oct-88 1432 hoffman@csli.Stanford.EDU time and place of the SSP Forum
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Oct 88 14:32:23 PDT
Received: by csli.Stanford.EDU (4.0/4.7); Sat, 1 Oct 88 14:32:01 PDT
Date: Sat 1 Oct 88 14:32:00-PDT
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: time and place of the SSP Forum
To: ssp-faculty@csli.Stanford.EDU, ssp-students@csli.Stanford.EDU,
ssp-forum@csli.Stanford.EDU
Message-Id: <591744720.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
The Symbolic Systems forum will be held at 3:15 on Fridays
in room 62N. Room 62N is on the second floor of the symbolic
systems building (#60), near the center of the building. The
symbolic systems building is on the right side of the Inner
Quad from memorial church as one walks into the Quad from the
Oval.
-------
∂01-Oct-88 1524 hoffman@csli.Stanford.EDU clarification
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Oct 88 15:23:55 PDT
Received: by csli.Stanford.EDU (4.0/4.7); Sat, 1 Oct 88 15:23:31 PDT
Date: Sat 1 Oct 88 15:23:30-PDT
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: clarification
To: ssp-faculty@csli.Stanford.EDU
Message-Id: <591747810.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
One slight clarification: in the hopes that they will come and participate
in the forum, all faculty will also receive all forum notices. The part
about sending me e-mail was left in just in case you have any compatriots
who would be interested in receiving information about the forum. Sorry for
the lack of clarity.
reid
-------
∂01-Oct-88 2348 hoffman@csli.Stanford.EDU Oct. 7
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Oct 88 23:48:34 PDT
Received: by csli.Stanford.EDU (4.0/4.7); Sat, 1 Oct 88 23:48:14 PDT
Date: Sat 1 Oct 88 23:48:13-PDT
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: Oct. 7
To: ssp-faculty@csli.Stanford.EDU, ssp-students@csli.Stanford.EDU,
ssp-forum@csli.Stanford.EDU
Message-Id: <591778093.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
October 7th will be a very informal meeting, with the agenda of discussing
some basic issues about the forum. These issues will include
institutionalization, once or twice per week forum, funding arrangements,
scheduling of this years forum (ideas + use of available contacts), and other
such issues. I encourage you to attend as input always makes things more
interesting, and it will likely be quite short.
-------
∂03-Oct-88 0907 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Tuesday lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Oct 88 09:07:52 PDT
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 3 Oct 88 09:03:21-PDT
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA11396; Mon, 3 Oct 88 08:57:15 PDT
Date: Mon, 3 Oct 88 08:57:15 PDT
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8810031557.AA11396@Tenaya.stanford.edu>
To: faculty@score
Subject: Tuesday lunch
Tomorrow, Tuesday October 4, we will host our architect Ted Brown
and some of his staff who will be unveiling their suggestions for
the rough shape of our new CS building. 12:15 in mjh 146. Other
guests will include the planning/project staff, ISL faculty, and
Dean Jim Gibbons (possibly). (I trust that all of CSL--including
the EE faculty--get announcements about our faculty lunches
routinely and know that they are always welcome, and thus I don't
think of them as "guests.") I have asked Joyce to order extra
sandwiches for what might turn out to be a SRO lunch.
-Nils
∂03-Oct-88 1122 X3J13-mailer Subcommittee Meetings at Contel
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Oct 88 11:22:04 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00587g; Mon, 3 Oct 88 10:19:33 PST
Received: by challenger id AA00351g; Mon, 3 Oct 88 11:15:46 PDT
Date: Mon, 3 Oct 88 11:15:46 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8810031815.AA00351@challenger>
To: x3j13@sail.stanford.edu
Subject: Subcommittee Meetings at Contel
Please note that the subcommittee meetings will be held at Contel. Ask for
Bob Mathis. Security will escort you to the meeting rooms.
---jan---
∂03-Oct-88 1252 X3J13-mailer Error terminology
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 Oct 88 12:52:40 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA06841; Mon, 3 Oct 88 12:51:06 PDT
Message-Id: <8810031951.AA06841@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 3 Oct 88 15:42
To: x3j13@sail.stanford.edu
Subject: Error terminology
Following is the proposed error terminology for the forthcoming standard. The
editorial committee has not completely finished shaking the bugs out of this
document, but we thought you might like to comment on it yourselves both
now and at the October meeting. We hope to have consensus on this terminology
in the near future so that it can be used during the writing of phase 2 of
the standard.
Thanks in advance for your review time.
Condition Terminology
September, 1988
Edited by Kathy Chapman, Kent Pitman, Walter Van Roggen
!
Page 2
1 INTRODUCTION
Common Lisp constructs are described in the forthcoming
standard in terms of their behavior in "situations" during which
they are intended to be used (see "Description" and
"Environment/Evaluation" parts of each construct specification),
and in all other "situations" (see "Conditions" part of
specification).
A "situation" is the evaluation of an expression in some
specific context. A "condition", represented by a condition
object, is a situation which has been detected. Some types of
conditions are predefined by the Common Lisp system, and all types
of conditions are subtypes of type CONDITION, i.e. (typep c
'condition) is true if and only if C is a condition. An "error"
is a condition in which normal program execution may not continue
without some form of intervention (either interactively by the
user or under some sort of program control).
"Signalling" is the process by which a situation is announced
by a program and SIGNAL is a mechanism by which such announcement
is done. ERROR and CERROR are also used to signal errors.
Signalling an error has no side-effect on the condition associated
with the error, and there is no dynamic state contained in a
condition object. The interactive interface for signalling is
implementation-dependent.
The process of signalling involves the search for and
invocation of a handler, which is a function of one argument (the
condition) that attempts to deal with the situation. Handlers are
established dynamically using HANDLER-BIND or abstractions built
on HANDLER-BIND such as HANDLER-CASE and IGNORE-ERRORS.
IGNORE-ERRORS is used to inhibit entry to the debugger when all
errors are detected, while HANDLER-CASE is used to perform
specified actions when the specified situations occur. If a
handler is found, it may either handle the situation by performing
some non-local transfer of control or "decline" by failing to
perform a non-local transfer of control. If it declines, other
handlers are sought. If no handler is found and the error was
signalled by ERROR or CERROR, the debugger is entered with no
context change.
The debugger prints the description of the situation
represented by the error being signalled along with contextual
information perhaps including information such as which function
detected the error. The debugger should prefix all lines in a
multiline condition message with the character or indentation used
in the first of the lines of the message. The debugger allows
interactive examination or modification of the state of the
program and restarting from the situation.
The condition object given to the handler is created
explicitly by an operation such as MAKE-CONDITION or implicitly by
an operation such as SIGNAL. The handler is executed in the
dynamic context of the program which has invoked it, except that
!
Page 3
the set of available condition handlers will have been rebound to
the value that was active at the time the condition handler was
made active.
2 TERMINOLOGY
Situations in which errors might, should, or must be
signalled are referred to in the standard. The wording used to
describe such situations is intended to have precise formal
meaning. The following list is a glossary of those meanings.
- A VALID PROGRAM
is a program whose code adheres to the requirements of
conforming code listed as follows:
- Conforming code shall not use any constructions that are
prohibited by the standard.
- Conforming code shall not depend on extensions included in
an implementation.
- Conforming code shall not use any extension included in an
implementation.
- A SAFE SITUATION
is a situation in which interpreted code, or code
compiled with the safest optimization level is run.
- AN UNSAFE SITUATION
is a situation in which code compiled with lower safety
levels is run.
- AN ERROR "IS SIGNALLED"
means that
- If this situation occurs, the error will be signalled, in
both safe and unsafe situations.
- Valid programs may rely on the fact that the error will be
signalled in both safe and unsafe situations.
- Every implementation is required to detect the error in
both safe and unsafe situations.
For example, "an `error is signalled' if UNEXPORT is
given a symbol not accessible in the current package."
!
Page 4
- AN ERROR "SHOULD BE SIGNALLED"
means that
- If this situation occurs, the error will be signalled in
safe situations but may not be signalled in unsafe ones.
- Valid programs may not rely on the fact that the error
will be signalled.
- Every implementation is required to detect the error at
least in safe situations.
- When the error is not signalled, the "consequences are
undefined" (see below).
In summary, the situation which has been identified as an
error is illegal in all implementations, but some
implementations do not actually detect the situation.
For example, "an error `should be signalled' if ENDP is
given a non-list argument."
- THE "CONSEQUENCES ARE UNDEFINED"
means that
- If this situation occurs, the consequences are
unpredictable. The consequences may range from harmless
to fatal.
- Implementations are allowed to detect this situation and
signal an error, but no implementation is required to
detect the situation.
- No valid program may depend on the effects of this
situation, and all valid programs are required to treat
the effects of this situation as unpredictable.
- In places where the words "must", "must not" or "may not"
are used, then "the consequences are undefined" if the
stated requirement is not met, and no specific consequence
is explicitly stated.
There are two principal reasons why this language permits
a situation to have an undefined consequence rather than
requiring an error to be signalled:
- Detecting the situation might be prohibitively expensive
in some or all implementations.
!
Page 5
- An "implementation may be extended" to cover this
situation.
For example, "the `consequences are undefined' is there
is an attempt to redefine the name of a special form."
- THE "RETURN VALUES ARE UNDEFINED"
means that only the number and nature of the return
values of a construct are not well defined but any side-effect
and transfer-of-control behavior is well defined.
For example, if the return values of some function F are
undefined, then an expression such as (length (list (F))) is
still well-defined because it does not rely on any particular
aspect of the value or values returned by F.
- THE "CONSEQUENCES ARE UNSPECIFIED"
means that
- The consequences of this situation are not specified in
the standard, but will not, by themselves, cause execution
to abnormally terminate.
- Implementations are allowed to specify the consequences of
this situation.
- No portable program can depend on the consequences of this
situation, and all portable programs are required to treat
the situation as unpredictable but harmless.
For example, "if the second argument to SHARED-INITIALIZE
specifies a name that does not correspond to any slots
accessible in the instance, the `consequences are
unspecified.'"
- "IMPLEMENTATIONS MAY BE EXTENDED" TO COVER THIS SITUATION
means that an implementation is free to treat the
situation in ANY ONE of the following ways.
1. When the situation occurs, an error is signalled at least
in safe situations,
OR
2. When the situation occurs, the "consequences are
undefined",
OR
!
Page 6
3. When the situation occurs, the consequences are defined
and specified.
Also, no portable program can depend on the consequences
of this situation, and all portable programs are required to
treat the consequences of the situation as undefined.
For example, "`implementations may be extended' to define
other type specifiers to have a corresponding class."
- IMPLEMENTATIONS ARE "FREE TO EXTEND THE SYNTAX"
means that in this situation
- Implementations are allowed to define unambiguous
extensions to the syntax of the construct being described.
- No portable program can depend on this extension, all
portable programs are required to treat the syntax as
meaningless.
The standard may disallow certain extensions while
allowing others.
For example, "no `implementation is free to extend the
syntax' of DEFCLASS."
- A "WARNING IS ISSUED"
means that
- If this situation occurs, a warning is issued, as
described in WARN, in both safe and unsafe situations.
- Valid programs may rely on the fact that a warning will be
issued in both safe and unsafe situations.
- Every implementation is required to detect this situation
in both safe and unsafe situations.
- The presence of a warning will in no way alter the value
returned by the form which caused the situation to occur.
For example, "a `warning is issued' by the compiler if a
declaration specifier is not one of those defined in Chapter 9
of CLtL and has not been declared in a DECLARATION
declaration."
- A "WARNING SHOULD BE ISSUED"
!
Page 7
means that
- If this situation occurs, a warning will be issued at
least in safe situations.
- Valid programs may not rely on the fact that a warning
will be issued.
- Every implementation is required to detect such a
situation at least in safe situations.
- The presence of a warning will in no way alter the value
returned by the form which caused the situation to occur.
For example, "a warning `should be issued' by a compiler
if a variable declared to be ignored is ever referred to or is
also declared special, or if a variable is lexical, never
referred to, and not declared to be ignored." (see Chapter 9,
CLtL)
∂04-Oct-88 1159 X3J13-mailer Hotel reservations for Hawaii
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Oct 88 11:58:04 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01362g; Tue, 4 Oct 88 10:55:36 PST
Received: by challenger id AA03260g; Tue, 4 Oct 88 11:53:17 PDT
Date: Tue, 4 Oct 88 11:53:17 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8810041853.AA03260@challenger>
To: x3j13@sail.stanford.edu
Subject: Hotel reservations for Hawaii
There seems to be a little confusion regarding my last note. I asked for the
dates people would be staying in Hawaii only as a reference point to extend
the time in which the reduced fee would be available. This was not an offer
to make hotel reservations. You should contact the hotel directly if you wish
to make reservations.
808/822-3455 ask for Liz Anne
Cheers!
---jan---
∂04-Oct-88 1638 helen@russell.Stanford.EDU SSP lunch meeting
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Oct 88 16:38:38 PDT
Received: by russell.Stanford.EDU (4.0/4.7); Tue, 4 Oct 88 16:38:15 PDT
Date: Tue 4 Oct 88 16:38:14-PDT
From: Helen Nissenbaum <HELEN@CSLI.Stanford.EDU>
Subject: SSP lunch meeting
To: ssp-faculty@russell.Stanford.EDU
Message-Id: <592011494.0.HELEN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
A reminder about October 21 SSP Faculty Meeting, at noon
in Cordura Hall Conference Room.
In my earlier message I forgot to get a "head count". I'll be ordering
lunch for all of us. Let me know if you can make it.
I'm putting together an agenda for the meeting. If there's something
you'd like discussed please let me know and I'll include it.
Helen
-------
∂04-Oct-88 1853 misha@polya.Stanford.EDU Next AFLB
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Oct 88 18:53:00 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA18172; Tue, 4 Oct 88 18:50:07 PDT
Date: Tue, 4 Oct 88 18:50:07 PDT
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8810050150.AA18172@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: Next AFLB
Next AFLB will meet as usual on Thursday, October 6, at 12:30
in room 352.
The talk will be:
Universal One-Way Hash Functions and their Cryptographic Applications
Moti Yung, IBM Almaden
We define a Universal One-Way Hash Function Family, a tool which enables the
compression of elements in the function domain. The main property of such a
family is that given an element x in the domain, it is computationally hard
to find a different domain element which collides with x.
We prove that Universal One-Way Hash Function exists if One-Way Function
exists.
Among the applications of the tool is a Secure Digital Signature Scheme.
Secure Signature Schemes were previously known to exist only under the
assumption that (specific and recently general) Trapdoor One-Way Functions
exist.
-a joint work with Moni Naor, Berkeley.
∂04-Oct-88 2041 X3J13-mailer Re: error definitions
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Oct 88 20:41:24 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 OCT 88 19:59:52 PDT
Date: Tue, 4 Oct 88 19:59 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: error definitions
To: Barry Margolin <barmar@Think.COM>, Dick Gabriel
<RPG@SAIL.Stanford.EDU>, chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@SAIL.Stanford.EDU, x3j13@sail.stanford.edu,
DJAHANDARI%TOWNS.DEC@decwrl.dec.com, POPA%TOWNS.DEC@decwrl.dec.com
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <19881003194959.0.BARMAR@OCCAM.THINK.COM>,
<OlxIJ@SAIL.Stanford.EDU>,
<19881003212644.4.BARMAR@OCCAM.THINK.COM>,
<8810031951.AA06841@decwrl.dec.com>,
<km9wo@SAIL.Stanford.EDU>
Message-ID: <19881005025941.6.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
Date: 04 Oct 88 11:01 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I might point out that the CLOS committee didn't come up with this
terminology as a joke or in a fit of stupidity. Nor did we accidentally
forget the CLtL terminology. We designed it deliberately and in full
knowledge that it differed from CLtL terminology. Furthermore, we used
that terminology very carefully in the CLOS document.
Right, and more detail about this to follow.
Date: 03 Oct 88 14:06 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I'm not following the debate on this, but I see the question raised
about what these two phrases mean:
1. ``consequences are undefined''
2. ``implementations may be extended''
This terminology was introduced after a great deal of thought about how
to prevent the so called "number of arguments to IF" bug. We believe
that we have restricted the syntactic extensions that can be made to
CLOS, and that that restriction is important for a variety of reasons.
CLOS is a language which provides a great deal of extensibility, and
given that it is a very important concept to be able to restrict that
in places where it is appropriate.
- THE "CONSEQUENCES ARE UNSPECIFIED"
I am not up to speed on this issue, and I am tired, but I believe it is
important that "THE CONSEQUENCES ARE UNSPECIFIED" must not include
"IMPLEMENTATIONS MAY BE EXTENDED" in any way.
-------
∂05-Oct-88 0255 bresnan@russell.Stanford.EDU Re: SSP lunch meeting
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Oct 88 02:55:14 PDT
Received: from localhost by russell.Stanford.EDU (4.0/4.7); Wed, 5 Oct 88 02:55:11 PDT
To: Helen Nissenbaum <HELEN@CSLI.Stanford.EDU>
Cc: ssp-faculty@russell.Stanford.EDU
Subject: Re: SSP lunch meeting
In-Reply-To: Your message of Tue, 04 Oct 88 16:38:14 PDT.
<592011494.0.HELEN@CSLI.Stanford.EDU>
Date: Wed, 05 Oct 88 02:55:10 PDT
From: bresnan@russell.Stanford.EDU
Helen, I think I can make it.
∂05-Oct-88 0920 SLOAN@Score.Stanford.EDU Water
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Oct 88 09:20:27 PDT
Date: Wed 5 Oct 88 09:09:47-PDT
From: Yvette Sloan <SLOAN@Score.Stanford.EDU>
Subject: Water
To: CSD-List@Score.Stanford.EDU
Message-ID: <12436025761.28.SLOAN@Score.Stanford.EDU>
Just got another telephone call!! The water shut-off will happen **tomorrow**
9:30-12:30 instead of today!!
--Yvette
-------
∂05-Oct-88 0956 DELAGI@SUMEX-AIM.Stanford.EDU [Sayuri Nishimura <NISHIMURA@SUMEX-AIM.Stanford.EDU>: portable window systems implementations]
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Oct 88 09:56:00 PDT
Date: Wed, 5 Oct 88 09:48:34 PDT
From: Bruce A. Delagi <DELAGI@SUMEX-AIM.Stanford.EDU>
Subject: [Sayuri Nishimura <NISHIMURA@SUMEX-AIM.Stanford.EDU>: portable window systems implementations]
To: aap@SUMEX-AIM.Stanford.EDU
Message-ID: <12436032820.52.DELAGI@SUMEX-AIM.Stanford.EDU>
fyi.../b
---------------
Mail-From: NISHIMURA created at 4-Oct-88 18:33:55
Date: Tue, 4 Oct 88 18:33:55 PDT
From: Sayuri Nishimura <NISHIMURA@SUMEX-AIM.Stanford.EDU>
Subject: portable window systems implementations
To: delagi@SUMEX-AIM.Stanford.EDU, saraiya@SUMEX-AIM.Stanford.EDU
Message-ID: <12435866312.51.NISHIMURA@SUMEX-AIM.Stanford.EDU>
There are four window system implementations presented at the CLOS workshop
today. The following is a brief summary.
1. Uncommon Windows: BBN, presented by Kenneth Anderson, kanderson@bbn.com
It is a CLOS based implementation Common Windows. The Common Windows
implementation by Franz-IntelliCorp is not object oriented but Uncommon Windows
is developed in CLOS and users can benefit from nice features of object oriented
programming like inheritance etc.
They showed us several slides which includes some example windows of our
insterest, such as a window with a scroll bar, a simple constraint frame
(care instrument windows are constraint frame windows).
Compared with the rest of three implementation of window systems in CLOS,
Uncommon Windows looked most useful to us.
BBN has another interesting program called FLOID, a Flavor Impersonator,
which may help us convert Care code from the flavor system to CLOS.
Kenneth Anderson told me the name of the person who is in charge of
distributing both Floid and Uncommon Windows. I asked Bob to make contact with
him about it.
2. Solo: SUN, presented by Hans Muller, hmuller@sun.com
It is a CLOS-based interface to X, NeWS and SunView. The design of Solo
departs from Interlisp window system and Common Windows in a few areas.
There is a toolkit called OPEN LOOK which specializes menus, buttons etc.
3. DWS: MCC, presented by Robert C. Pettengil, rcp%sw.MCC.COM@MCC.COM
Deli Window System, DWS, is portable since it is built on WSII, Window System
Independent Interface, which allows DWS application interfaces to run on any
server running X and NeWS window systems. (NeWS interface is complete, clx-X11
interface is nearly complete.) He says the performance is modest. DWS was
originally developed for the internal use of MCC, but they are thinking of
passing the DWS package to a vender which can distribute the code. There is some
toolkit available including a browser and an editor interface(GNU emacs).
4. SharkII: Advanced Decision Systems, presented by John Dye, jdye@ads.com
SharkII is built on the Sun NeWS version 1.1 window systems and currently
working on SUN workstations. Some issues of possible improvements includes
o memory management to utilize resources
o porting to vendor-supplied platforms like Common Windows.
There seems to be a project at MITRE which is forcusing on CLOS and CLUE,
but the article in the procedings does not tell the details of it and the
presenter did not show up.
sayuri
-------
-------
∂05-Oct-88 1003 SLOAN@Score.Stanford.EDU Water
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Oct 88 10:03:20 PDT
Date: Wed 5 Oct 88 09:41:25-PDT
From: Yvette Sloan <SLOAN@Score.Stanford.EDU>
Subject: Water
To: CSD-List@Score.Stanford.EDU
Message-ID: <12436031519.28.SLOAN@Score.Stanford.EDU>
The domestic water in MJH will be shut-off tomorrow (10/6) from (9:30-12:30).
--Yvette
-------
∂05-Oct-88 1259 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu WG '89 Call for Papers
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Oct 88 12:59:03 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA26474; Wed, 5 Oct 88 12:57:28 PDT
Message-Id: <8810051957.AA26474@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 5 Oct 88 12:58:14 PDT
Received: by BYUADMIN (Mailer X1.25) id 3451; Wed, 05 Oct 88 13:56:28 MDT
Date: Wed, 5 Oct 88 09:45:01 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Jan van Leeuwen <jan%RUUINF.UUCP@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Jan van Leeuwen <jan%RUUINF.UUCP@Forsythe.Stanford.EDU>
Subject: WG '89 Call for Papers
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
C A L L F O R P A P E R S
WG 89
15th International Workshop on
Graph-Theoretic Concepts in Computer Science
June 14-16, 1989, near Aachen
The 15th International Workshop WG 89 will be held at Rolduc Castle in the
Netherlands, only a few miles away from Aachen, West Germany. The Workshop
is intended to provide a forum for researchers interested in the study and
application of graph-theoretic concepts in computer science.
The Workshop covers graph-theoretic topics like structural graph theory,
sequential and parallel graph algorithms and their complexity, graph-based
modelling (structure of graph classes, graph-grammars), graphs and represen-
tations, randomness. The specific value of this Workshop is to demonstrate the
applicability of graph-theoretic concepts to a broad range of application areas
like databases, data structures, programming languages, software engineering,
geometry and graphics, distributed systems, VLSI. The list of graph-theoretic
topics and application areas is not meant to be exhaustive.
The WG Workshops are well-known because of their pleasant atmosphere. There
is an upper limit of about 70 participants and the location of the workshop
allows for excellent scientific and personal contacts of participants. Some
social events are planned. The tradition of the WG Workshops traces back
to 1975.
Papers will go through a strict selection process with about 30 papers being
accepted for presentation and for proceedings. Proceedings will be published
in the fall of 1989 by an international publishing company. Presentations and
papers must be given in English.
SUBMISSIONS: Please send 6 copies of your paper (15 pages maximum, not a
brief abstract) to:
Professor Manfred Nagl
Lehrstuhl f. Informatik III
RWTH Aachen
Ahornstr. 55, D-5100 Aachen, West Germany
Submission Deadline: March 1, 1989
Acceptance Notification: May 1, 1989
Camera-ready paper due: August 1, 1989
PROGRAM COMMITTEE: H. Bunke (Bern), B. Courcelle (Bordeaux), J. van Leeuwen
(Utrecht), M. Nagl (Chairman, Aachen), H. Noltemeier (Wuerzburg), and
H. J. Schneider (Erlangen).
∂05-Oct-88 1405 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu the hardest language
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Oct 88 14:05:42 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA02351; Wed, 5 Oct 88 14:03:56 PDT
Message-Id: <8810052103.AA02351@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 5 Oct 88 14:04:32 PDT
Received: by BYUADMIN (Mailer X1.25) id 4426; Wed, 05 Oct 88 15:02:50 MDT
Date: Wed, 5 Oct 88 14:11:45 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
lescanne%POINCARE.CRIN.FR@Forsythe.Stanford.EDU
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: lescanne%POINCARE.CRIN.FR@Forsythe.Stanford.EDU
Subject: the hardest language
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
I heard about a concept called the hardest language. Can someone give
me references or pointers?
Pierre LESCANNE
Centre de Recherche en Informatique de Nancy
telephone: 83 91 21 19 (country code is 33)
e-mail: lescanne@poincare.crin.fr
post: BP 239, F54506 VANDOEUVRE Cedex FRANCE
∂05-Oct-88 1436 @Score.Stanford.EDU:DEK@SAIL.Stanford.EDU email deluge
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Oct 88 14:36:45 PDT
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 5 Oct 88 14:32:15-PDT
Message-ID: <1Wmxcl@SAIL.Stanford.EDU>
Date: 05 Oct 88 1434 PDT
From: Don Knuth <DEK@SAIL.Stanford.EDU>
Subject: email deluge
To: faculty@SCORE.Stanford.EDU
Does everybody really want me to announce all the meetings of the
"theory" search committee? If so, let me know and I'll put you on the
mailing list. If not, I'll not clutter up your mail files, even though
there's a rumor we voted to do something like that in June.
Anyway, our committee's first meeting will be Tuesday Oct 11 at 4pm in MJH301.
Volunteers are welcome, as there is a lot of work to share around. (Search
committees are almost like admissions committees these days!)
∂05-Oct-88 1543 DELAGI@SUMEX-AIM.Stanford.EDU [Sayuri Nishimura <NISHIMURA@SUMEX-AIM.Stanford.EDU>: Re: [Sayuri Nishimura <NISHIMURA@SUMEX-AIM.Stanford.EDU>: porta
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Oct 88 15:42:05 PDT
Date: Wed, 5 Oct 88 15:33:16 PDT
From: Bruce A. Delagi <DELAGI@SUMEX-AIM.Stanford.EDU>
Subject: [Sayuri Nishimura <NISHIMURA@SUMEX-AIM.Stanford.EDU>: Re: [Sayuri Nishimura <NISHIMURA@SUMEX-AIM.Stanford.EDU>: portable window systems implementations]]
To: aap@SUMEX-AIM.Stanford.EDU
Message-ID: <12436095570.52.DELAGI@SUMEX-AIM.Stanford.EDU>
Mail-From: NISHIMURA created at 5-Oct-88 11:22:03
Date: Wed, 5 Oct 88 11:22:03 PDT
From: Sayuri Nishimura <NISHIMURA@SUMEX-AIM.Stanford.EDU>
Subject: Re: [Sayuri Nishimura <NISHIMURA@SUMEX-AIM.Stanford.EDU>: portable window systems implementations]
To: DELAGI@SUMEX-AIM.Stanford.EDU
In-Reply-To: <12436032820.52.DELAGI@SUMEX-AIM.Stanford.EDU>
Message-ID: <12436049839.32.NISHIMURA@SUMEX-AIM.Stanford.EDU>
I forgot to tell you about one thing about Common Windows.
A big disadvantage of uncommon windows is currently (I believe) implemented
only on Symbolics, while IntelliCorp implemented Common Windows
on at least 5 different machines including Symbolics and Explores according to
the 2 year old documentation. We will get the latest documentation from IntelliCorp
soon.
sayuri
-------
-------
∂05-Oct-88 1545 DELAGI@SUMEX-AIM.Stanford.EDU [Sayuri Nishimura <NISHIMURA@SUMEX-AIM.Stanford.EDU>: Re: [Sayuri Nishimura <NISHIMURA@SUMEX-AIM.Stanford.EDU>: porta
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Oct 88 15:45:14 PDT
Date: Wed, 5 Oct 88 15:35:13 PDT
From: Bruce A. Delagi <DELAGI@SUMEX-AIM.Stanford.EDU>
Subject: [Sayuri Nishimura <NISHIMURA@SUMEX-AIM.Stanford.EDU>: Re: [Sayuri Nishimura <NISHIMURA@SUMEX-AIM.Stanford.EDU>: portable window systems implementations]]
To: aap@SUMEX-AIM.Stanford.EDU
Message-ID: <12436095927.52.DELAGI@SUMEX-AIM.Stanford.EDU>
Mail-From: NISHIMURA created at 5-Oct-88 11:49:39
Date: Wed, 5 Oct 88 11:49:39 PDT
From: Sayuri Nishimura <NISHIMURA@SUMEX-AIM.Stanford.EDU>
Subject: Re: [Sayuri Nishimura <NISHIMURA@SUMEX-AIM.Stanford.EDU>: portable window systems implementations]
To: DELAGI@SUMEX-AIM.Stanford.EDU
In-Reply-To: <12436032820.52.DELAGI@SUMEX-AIM.Stanford.EDU>
Message-ID: <12436054862.32.NISHIMURA@SUMEX-AIM.Stanford.EDU>
My statement about the IntelliCorp Common Windows was wrong. According
to the 1986 documentation, it is object-oriented but it does not
support method combination except a simple form of wrapper and the inheritance
is limited. It looks like an object is implemented by something similar
to defstruct. The documentation says, "When Common Lisp supports an object system,
Common Windows will be implemented in that system", we will see what the
curent status is when we get the latest spec and documentation.
sayuri
-------
-------
∂05-Oct-88 1607 @Score.Stanford.EDU:tom@polya.Stanford.EDU Dover problems and Phase out
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Oct 88 16:06:59 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 5 Oct 88 16:02:46-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA11606; Wed, 5 Oct 88 16:03:53 PDT
Date: Wed, 5 Oct 88 16:03:53 PDT
From: Tom Dienstbier <tom@polya.Stanford.EDU>
Message-Id: <8810052303.AA11606@polya.Stanford.EDU>
To: csd@score, su-computers@score, faculty@score
Subject: Dover problems and Phase out
Dover is having laser problems and will be out of commission through today
and possibly tomorrow. As this printer is nearing phase out, it may be wise
for the last of the dedicated users, to start the switch over to other
printing devices (Apple Laserwriters, LPS40's, Imagens, etc). The phase out
will be planned in December( of this year) or a complex hardware
problem may speed up this planned phase out.
Tom
∂05-Oct-88 1615 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Dover problems and Phase out
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Oct 88 16:15:47 PDT
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 5 Oct 88 16:11:23-PDT
Message-ID: <1OmzvH@SAIL.Stanford.EDU>
Date: 05 Oct 88 1613 PDT
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: Dover problems and Phase out
To: tom@POLYA.STANFORD.EDU
CC: csd@SCORE.Stanford.EDU, su-computers@SCORE.Stanford.EDU,
faculty@SCORE.Stanford.EDU
The Dover phase out could happen a lot more smoothly if TeX on Score were
not set up to print by default to the Dover. This involves creating a
trivial program (called DVISPOOL or DVI-ELM or DVI-SZEGO) that causes the
DVI file to be transmitted to the spooling host. This program is needed
because of a limitation of TOPS-20 that requires that DVISPOOL: be defined
to refer to a file (i.e., a program) and cannot refer to an EXEC command
(e.g., PRINT). Can we see some action on the creation of this program?
Arthur
∂05-Oct-88 1726 emma@csli.Stanford.EDU CSLI Calendar, October 6, 4:3
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Oct 88 17:26:01 PDT
Received: by csli.Stanford.EDU (4.0/4.7); Wed, 5 Oct 88 16:42:33 PDT
Date: Wed, 5 Oct 88 16:42:33 PDT
From: emma@csli.Stanford.EDU (Emma Pease)
To: friends@csli.Stanford.EDU
Subject: CSLI Calendar, October 6, 4:3
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
6 October 1988 Stanford Vol. 4, No. 3
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR NEXT THURSDAY, 6 October 1988
12 noon TINLab
Cordura Hall What is Unification Grammar?
Conference Room Martin Kay
(Kay.pa@xerox.com)
Abstract in last week's Calendar
2:15 p.m. CSLI Seminar
Cordura Hall Resolution: Some Approaches to the Problem
Conference Room Ivan Sag
(sag@csli.stanford.edu)
3:45 p.m. Tea
Ventura Hall
____________
CSLI ACTIVITIES FOR NEXT THURSDAY, 13 October 1988
12 noon TINLunch
Cordura Hall Readings: "Situation Semantics and Semantic
Conference Room Interpretation in Constraint-Based Grammars"
by Per-Kristian Halvorsen and
"Projections and Semantic Description in
Lexical-Functional Grammar"
by Per-Kristian Halvorsen and Ronald M. Kaplan
discussion led by Mary Dalrymple
(maryd@ai.sri.com)
Abstract in next week's Calendar
2:15 p.m. CSLI Seminar
Cordura Hall Psychological Processes in Resolution
Conference Room Herb Clark
(herb@psych.stanford.edu)
Abstract in next week's Calendar
3:45 p.m. Tea
Ventura Hall
∂06-Oct-88 0733 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu CICSR Distinguished Lecture Series
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Oct 88 07:33:36 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA04818; Thu, 6 Oct 88 07:32:06 PDT
Message-Id: <8810061432.AA04818@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 6 Oct 88 07:32:51 PDT
Received: by BYUADMIN (Mailer X1.25) id 4204; Thu, 06 Oct 88 08:28:06 MDT
Date: Thu, 6 Oct 88 09:21:15 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Nou Dadoun <dadoun%CS.UBC.CA@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Nou Dadoun <dadoun%CS.UBC.CA@Forsythe.Stanford.EDU>
Subject: CICSR Distinguished Lecture Series
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
The Centre for Integrated Computer Systems Research (CICSR) at the
University of British Columbia has planned a distinguished lecture series
for the 1988-89 academic year.
-------------------------------------------------------------------------
Professor David Dobkin,
Computer Science Department,
Princeton University
Computational Geometry and Computer Graphics:
Life on the Interface
TIME: Thursday, October 13th, 1988 at 11:30 am
PLACE: Room 104, Henry Angus Building,
University of British Columbia
-------------------------------------------------------------------------
Tentatively scheduled upcoming speakers include:
Professor Tom Leighton (Dec. 1),
Professor David Cheriton (Feb. 2),
Professor Bill Reeves (Late Feb. or early March), and
Professor Alan Borodin (Late March).
∂06-Oct-88 0808 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Oct 88 08:08:39 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA05323; Thu, 6 Oct 88 08:07:09 PDT
Message-Id: <8810061507.AA05323@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 6 Oct 88 08:07:55 PDT
Received: by BYUADMIN (Mailer X1.25) id 4794; Thu, 06 Oct 88 09:05:14 MDT
Date: Thu, 6 Oct 88 09:52:57 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Date: 6 Oct 1988 10:37-EST
From: mishra@sbcs.sunysb.edu (Prateek Mishra)
Subject: Simplifying sets of inclusions..
Message-Id: <592151840/mishra@sbstaff2>
Simplifying sets of inclusions representing constraints
_________________________________________________
I am looking for references for the following problem:
BACKGROUND:
Let R be a finite set of inclusion statements of the form "a <= b"
over a set of Observable variables {o1,o2,...,om} and Internal
Variables {i1,i2,i3,...,ip}. Let V be an arbitrary partially ordered set of
values and I a set of bindings (functions from Observable
and Internal Variables into V). Binding i satisfies R iff
every inclusion statement "a <= b" in R holds under i
(i.e. the statement i(a) <= i(b) holds in V). Let I(R) be the set of
bindings that satisfy R.
Bindings i1, i2 are observation equivalent iff they agree
on the entire set of observable variables.
Binding sets I1 and I2 are observation equivalent iff
for each binding in I1 there is an observation equivalent binding in I2
and for each binding in I2 there is an observational equivalent binding in I1.
Inclusion sets R and S are observation equivalent iff I(R) and I(S)
are observation equivalent.
QUESTION:
(i) Given inclusion sets R and S determine whether they are observation equivale
(ii) Given inclusion set R does there exist a unique minimal inclusion set R'
observation equivalent to R? If so, how hard is it to compute R'?
INTUITION:
The idea
here is that R describes a constraint on the possible values for observable
variables.
Ex1. R = {o1 <= i1, o2 <= i1}
any bindings for o1 and o2 are such that they have a common predecessor value i1
Many sets may have equivalent information; for instance R in Ex1 above
is equivalent to
S= {o1 <=i1, o2 <=i1, o1 <= i3, i4 <= i3, i4 <= i5, o2 <= i5}
I am looking for methods that could determine that inclusion
set S above was ``redundant'' and simplify it to R.
Thanks,
- prateek mishra
mishra@sbcs.sunysb.edu
∂06-Oct-88 1031 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Best Student Paper Award for 1989 STOC
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Oct 88 10:30:53 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA12245; Thu, 6 Oct 88 10:29:00 PDT
Message-Id: <8810061729.AA12245@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 6 Oct 88 10:29:40 PDT
Received: by BYUADMIN (Mailer X1.25) id 6706; Thu, 06 Oct 88 11:28:00 MDT
Date: Thu, 6 Oct 88 12:19:11 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Christos Papadimitriou <christos%cs%UCSD.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Christos Papadimitriou <christos%cs%UCSD.EDU@Forsythe.Stanford.EDU>
Subject: Best Student Paper Award for 1989 STOC
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
This is an addendum to the Call for Papers for the 1989 Symposium on the
Theory of Computing, which appeared recently on TheoryNet.
SIGACT has established a Best Student Paper Award for STOC. It will be
awarded to the best paper (as judged by the program committee) all of
whose authors are students. The amount ofg the award is $500.
Student authors submitting their abstract to the program committee should
indicate in the letter of submittal that they are eligible and wish to
be considered for the prize.
Christos Papadimitriou
PS: STOC 89 will be held from Monday to Wednesday, May 15-17 1989
(and not 14-16, as was mistakenly announced in the call on TheoryNet).
CHP.
∂06-Oct-88 1249 X3J13-mailer Issue: ERROR-NOT-HANDLED (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Oct 88 12:49:33 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472004; Thu 6-Oct-88 15:48:14 EDT
Date: Thu, 6 Oct 88 15:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ERROR-NOT-HANDLED (Version 1)
To: X3J13@SAIL.Stanford.EDU
Message-ID: <881006154802.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
The following issue will be presented at the upcoming meeting.
We might try to vote on this if people feel it non-controversial
enough, but the "two-week rule" could be invoked to suppress a
vote if someone felt they had inadequate time to consider it.
-----
Issue: ERROR-NOT-HANDLED
References: Interactive Condition Handling (Condition System, Rev 18, p19)
Category: CLARIFICATION/CHANGE
Edit history: 25-Sep-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
For delivery purposes, some implementations will want to leave out
major sections of runtime support in programs that do not require
them. The debugger is one such section.
However, since ERROR may be called implicitly by a number of Common
Lisp built-in functions, and since the condition system as currently
described insists that the interactive debugger be entered if a
condition is unhandled, the interactive debugger must be retained in
a saved image of any program that might signal an error unless the
compiler can prove that the error will never go unhandled. This
may be undesirable in some cases and may cause unnecessary bloating
of the saved image.
Proposal (ERROR-NOT-HANDLED:PERMIT-TERMINATION):
Permit implementors to designate an implementation-specific mechanism
for asking that unhandled errors cause `termination of the running
program' rather than entry into the system's debugger.
Implementations choosing to offer such a facility must clearly define
the nature and scope of such program termination, since the concept
of `program termination' is an ill-defined concept in present-day
Common Lisp.
Even when program termination rather than debugger entry would be
the ultimate effect of an unhandled error, the value of
*DEBUGGER-HOOK* (if non-NIL) must be called to provide programmers
the ability of customized debugging.
All implementations must at least provide the option of a system
debugger for use in program development.
Test Case:
(ERROR "Foo"), if unhandled, must now enter the debugger.
Under this proposal, it might also `terminate program execution'
in implementations which choose to provide such a facility and to
clearly define that concept.
Rationale:
Although technically an incompatible change, we're dealing at
the very edge of what the user can expect from the system. Once
an error is signalled and not handled, we're in the domain of
implementation-dependent effect anyway.
Current Practice:
Probably no one does this yet.
Cost to Implementors:
None. This change is upward compatible with existing implementations.
Cost to Users:
None.
Cost of Non-Adoption:
Saved Lisp images might be forced to be gratuitously larger than
they need to be in some implementations.
Benefits:
Addressing this issue will make Lisp more able to compete with
other languages which permit small saved images to result from
small user programs.
Aesthetics:
No significant impact.
Discussion:
This change was requested by Christian Queinnec of France
(queinnec@inria.inria.fr). Pitman supports the change.
∂06-Oct-88 1313 @Score.Stanford.EDU:jjones@polya.Stanford.EDU Re: Water
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Oct 88 13:13:31 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 6 Oct 88 13:00:25-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA24849; Thu, 6 Oct 88 13:01:35 PDT
Date: Thu, 6 Oct 88 13:01:35 PDT
From: James B. Jones <jjones@polya.Stanford.EDU>
Message-Id: <8810062001.AA24849@polya.Stanford.EDU>
To: CSD-List@Score.Stanford.EDU, SLOAN@Score.Stanford.EDU
Subject: Re: Water
what water shutoff?
∂06-Oct-88 1317 X3J13-mailer Fairfax Registration
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Oct 88 13:17:15 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00489g; Thu, 6 Oct 88 13:16:04 PDT
Received: by challenger id AA05749g; Thu, 6 Oct 88 13:12:27 PDT
Date: Thu, 6 Oct 88 13:12:27 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8810062012.AA05749@challenger>
To: x3j13@sail.stanford.edu
Subject: Fairfax Registration
X3J13 Attendee Information
10/05/88
Name Institute Paid L1 L2
Jim Allard Gensym - y y
Jim Antonisse The MITRE Corporation - y -
Bill Arbaugh U.S. Army AI Center - y y
Kim Barrett USC - - -
Kim Barrett Integrated Inference Machines y y y
David Bartley TI y y y
Paul Beiser HP - y y
Danny Bobrow Xerox y y y
Mary Boelk Johnson Controls - y y
Skona Brittian MSC y y y
Tom Bucken Prime Computer y - -
Kathy Chapman Digital Equipment Corporation - - -
Chris Dabrowski NBS - - -
Jeff Dalton University of Edinburgh - y y
Jerry Duggan HP - y y
Dick Gabriel Lucid, Inc. - y y
David Gray TI y y y
George Hadden Honeywell Systems \& Research - y y
Gregor Kiczales Xerox PARC - y y
Timothy Koschmann Southern Illinois University y y y
Aaron Larson Honeywell - y y
Thom Linden IBM y y y
David Loeffler MCC - y y
Sandra Loosemore University of Utah - y y
Barry Margolin Thinking Machines y y y
Larry Masinter Xerox PARC y y y
Bob Mathis Contel - y y
Tracey Miles Unisys - y y
Crispin Perdue Sun Microsystems - y y
Dan Pierson Encore - y y
Kent Pitman Symbolics y y y
Jeff Rosenking ISI - y y
Rick Tucker Mitre Corporation - y y
Tom Turba Unisys y - y
David Unietis Lucid, Inc. - y y
Mary Van Deusen IBM Research y y y
Walter van Roggen Digital Equipment Corporation - y y
Ellen Waldrum TI - y y
JonL White Lucid, Inc. - y y
Jan Zubkoff Lucid, Inc. - y y
----------------
35 35
∂06-Oct-88 1328 X3J13-mailer Revised DRAFT Agenda
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Oct 88 13:28:44 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00522g; Thu, 6 Oct 88 13:27:37 PDT
Received: by challenger id AA05784g; Thu, 6 Oct 88 13:24:00 PDT
Date: Thu, 6 Oct 88 13:24:00 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8810062024.AA05784@challenger>
To: x3j13@sail.stanford.edu
Subject: Revised DRAFT Agenda
**************DRAFT**************
X3J13 Committee Meeting Agenda
October 11 - 12, 1988
1 Call to Order, October 11, 9:00am
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
- Report on ISO meeting, Dick Gabriel
- Report on Scheme meeting, David Bartley
3 Approval of Agenda
4 Approval of Minutes
5 Character Subcommittee Report and Vote, Thom Linden (3 hrs)
6 Lunch, 12:00pm - 1:00pm
7 CLOS Workshop Report, Danny Bobrow (20 minutes)
8 CLOS Chapter 3, Gregor Kiczales (20 minutes)
9 Loop, JonL White (20 minutes)
10 Compiler Subcommittee Report and Vote, Sandra Loosemore (2 hrs)
11 Editorial Subcommittee Report, Kathy Chapman (30 minutes)
12 Recess, 5:00pm
13 Call to Order, October 12, 9:00am
14 Clean-up, Larry Masinter
15 Lunch, 12:00pm - 1:00pm
16 Registry for Packages, Modules, Features, Larry Masinter (15 minutes)
17 Public-ftp access, Larry Masinter (15 minutes)
18 Other committee reports
19 Adjournment, 5:00pm
20
!
Next meeting: 1/16 - 1/18 1989 Kauaii Hawaii
∂06-Oct-88 1517 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Minutes - 9-27 Faculty Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Oct 88 15:17:33 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 6 Oct 88 15:13:22-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA05400; Thu, 6 Oct 88 15:14:28 PDT
Date: Thu, 6 Oct 1988 15:13:59 PDT
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, admin@score
Subject: Minutes - 9-27 Faculty Meeting
Message-Id: <CMM.0.87.592179239.chandler@polya.stanford.edu>
The minutes to the subject meeting were sent out today WITHOUT the faculty
secretarial policy attachment. If you are interested in seeing this
attachment, please let me know and I'll get one to you. For those of you who
attended the meeting, you were given this information in your folder. Sorry
for the mix-up.
∂06-Oct-88 1714 X3J13-mailer X3J13 issues to be emailed: stay tuned for barrage
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 17:14:03 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 17:09:44 PDT
Date: 6 Oct 88 17:09 PDT
From: masinter.pa@Xerox.COM
Subject: X3J13 issues to be emailed: stay tuned for barrage
To: X3J13@Sail.stanford.edu
Message-ID: <881006-170944-1740@Xerox>
We have had a huge barrage of mail on numerous cleanup
issues; a number have come in at the last minute.
Some issues are ready for voting at X3J13; it will be nice
to get as many of these out of the way as possible. Others,
as will be identified, are in draft form and not ready for voting; we'll
cover the issue at the plenary session in any case, since we
need to have all open issues completely resolved by
the January meeting.
I hope to have hardcopy available at the meeting as well.
∂06-Oct-88 1718 X3J13-mailer Issue: ALIST-NIL (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 17:18:30 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 17:12:44 PDT
Date: 6 Oct 88 17:12 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: ALIST-NIL (Version 4)
To: x3j13@SAIL.Stanford.EDU
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: NO
Message-ID: <881006-171244-1747@Xerox>
!
Issue: ALIST-NIL
References: Definition of "a-list" (p279), ASSOC (p280)
Category: CHANGE
Edit history: 20-Jun-88, Version 1 by Pitman
04-Sep-88, Version 2 by Masinter (reflect discussion)
21-Sep-88, Version 3 by Masinter (minor edits)
01-Oct-88, Version 4 by Pitman (remove some bias)
Problem Description:
NIL is permitted to be an element of an a-list but very little of
use can be done with such an element, and the idea can be confusing.
In most situations where an a-list entry is to be removed, it is
done by straightfoward uses like
(SETQ THE-ALIST (REMOVE THE-ENTRY THE-ALIST))
or (SETQ THE-ALIST (DELETE THE-ENTRY THE-ALIST)).
Relatively few situations require the more advanced technique of
(SETF (CAR THE-ALIST-TAIL) NIL)
in order to remove an entry from a list. Usually these situations
involve multiple pointers into different parts of the same a-list,
or very long a-lists where DELETE or REMOVE would take a long time.
Proposal ALIST-NIL:DISALLOW:
Change the definition of an a-list to require all elements to be
real conses. Uses of ASSOC with non-standard a-list would be an error.
Test Case:
(ASSOC 'X '(NIL (X . 3)))
is currently defined to return (X . 3).
Under this proposal, this would be an error.
Rationale:
An a-list is a commonly used data structure that should be easy to
explain. Permitting NIL in an a-list complicates the description
considerably.
This change would make the relationship between FIND (with key of
#'CAR) and ASSOC simpler and easier to explain.
Current Practice:
All valid implementations permit NIL in an a-list.
Cost to Implementors:
Since the proposal is to make this an "is an error" situation, no
implementation would be forced to change.
Cost to Users:
There are two basic ways in which we expect this feature is used
currently.
#1: A user wants a leading NIL on an a-list so that if the list
is empty, there's still be a tail to which cells could be
attached in the future. That is,
(DEFVAR *MY-ALIST* (CONS NIL '()))
so that
...(NCONC *MY-ALIST* (LIST new-cell))...
would always be possible as a side-effect and
...(ASSOC element *MY-ALIST*)...
would always be possible for lookup. It might be argued that
this is more clearly written:
(DEFVAR *MY-TABLE* (CONS NIL '()))
(DEFUN ADD-ENTRY (ENTRY TABLE) (NCONC TABLE (LIST ENTRY)))
(DEFMACRO MY-TABLE-CONTENTS (X) `(CDR ,X))
...(ADD-ENTRY new-cell *MY-TABLE*)...
...(ASSOC element (MY-TABLE-CONTENTS *MY-TABLE*))...
#2: A user might want to splice out an element from an a-list, preserving
the place that the element occupied in the list. In the very rare cases
where this was necessary, one could rewrite:
(DEFUN VOID-FIRST-ENTRY (ALIST) (SETF (CAR ALIST) NIL))
as:
(DEFUN VOID-FIRST-ENTRY (ALIST)
(LET ((ENTRY (CONS NIL NIL)))
(SETF (CAR ENTRY) (GENSYM)) ;or ENTRY or something otherwise unique
(SETF (CAR ALIST) ENTRY)))
This might change the behavior of ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF
and RASSOC-IF-NOT depending on the predicate used.
Also, in this case, the user must also consider that whatever is used
as the unique key must be acceptable to ASSOC.
In rare cases where neither of these rewrites were acceptable, the user could
still write his own variant of ASSOC to handle NIL even if the system version
did not.
Cost of Non-Adoption:
The only consequence of non-adoption is the burden of carrying around
the additional complexity in each implementation, in the documentation,
and in teaching. The cost of this burden is likely to be a subjective
matter.
Benefits:
FIND (with a :KEY of #'CAR) and ASSOC (with no key) would be identical.
Aesthetics:
This change would simplify the language.
Discussion:
The description of association lists is currently cluttered by this
unmotivated feature; no strong motivation or widespread use
of the feature has been found.
Some people consider this change gratuitous.
The cleanup committee discussed some interesting optimizations
of ASSOC where the existing situation (special-casing NIL) didn't
actually cost in performance (at least in the special case where
the predicate was EQ or EQL), so performance issues were dismisse
d
as a rationale for this change.
∂06-Oct-88 1752 X3J13-mailer Arpanet access during Dallas PI meeting
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Oct 88 17:52:18 PDT
Received: from DUE-PROCESS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 141274; Thu 6-Oct-88 20:51:07 EDT
Date: Thu, 6 Oct 88 20:51 EDT
From: Carl Hewitt <Hewitt@XX.LCS.MIT.EDU>
Subject: Arpanet access during Dallas PI meeting
To: Bill Arbaugh <arbaugh@hqda-ai.ARPA>
cc: x3j13@sail.stanford.edu, Hewitt@XX.LCS.MIT.EDU
In-Reply-To: <8809302043.AA02302@hqda-ai.ARPA>
Message-ID: <19881007005108.0.HEWITT@DUE-PROCESS.AI.MIT.EDU>
Bill,
I would like to obtain a TAC card.
Thanks,
Carl
∂06-Oct-88 1806 X3J13-mailer Issue: ARGUMENTS-UNDERSPECIFIED (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 18:06:04 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 18:02:04 PDT
Date: 6 Oct 88 18:02 PDT
From: masinter.pa@Xerox.COM
to: x3j13@Sail.Stanford.Edu
cc: Masinter.pa@Xerox.COM
line-fold: NO
Subject: Issue: ARGUMENTS-UNDERSPECIFIED (Version 4)
Message-ID: <881006-180204-1855@Xerox>
apologies if you got this twice; there was a mailer hiccup here.
!
Issue: ARGUMENTS-UNDERSPECIFIED
References: LOGBITP (p 224), MAKE-DISPATCH-MACRO-CHARACTER (p 363),
MAKE-HASH-TABLE (p 283), MAKE-SEQUENCE (p 249), READ (p 375)
MAKE-STRING (p 302), NTHCDR (p 267), PARSE-INTEGER (p 381),
SET (p 92)
Issue: RANGE-OF-START-END-PARAMETERS.
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
4-Sep-88, version 2 by Masinter
19-Sept-88, Version 3 by Chapman
21-Sep-88, Version 4 by Masinter
Problem Description:
The descriptions of LOGBITP, MAKE-DISPATCH-MACRO-CHARACTER, READ, SET,
MAKE-HASH-TABLE, MAKE-SEQUENCE, MAKE-STRING, NTHCDR, and PARSE-INTEGER
are not clear about the types of the arguments supplied to these
constructs.
Proposal (ARGUMENTS-UNDERSPECIFIED:SPECIFY)
Clarify that the arguments for the listed constructs are as follows:
Construct Argument Type
LOGBITP index non-negative integer
MAKE-DISPATCH-MACRO-CHARACTER char character
MAKE-HASH-TABLE size non-negative integer
MAKE-SEQUENCE size non-negative integer
MAKE-SEQUENCE type type specifier
MAKE-STRING size non-negative integer
MAKE-STRING initial-element string-char
NTHCDR n non-negative integer
SET-SYNTAX-FROM-CHAR to-char,from-char characters
READ and others eof-value any value
SET value any value
(MAKE-HASH-TABLE, MAKE-SEQUENCE, MAKE-STRING have additional constraints on
their respective SIZE arguments; for example, MAKE-STRING may detect an error if
SIZE is greater than or equal to ARRAY-DIMENSION-LIMIT. Some additional
restriction on the range of characters which can have syntax in readtables
and are allowable to MAKE-DISPATCH-MACRO-CHARACTER SET-SYNTAX-FROM-CHAR might
be required in some other proposal.)
Rationale:
This clarification allows predictible results to occur when
arguments are supplied to these constructs.
Current Practice:
This proposal seems to be in line with current implementations.
Cost to Implementors:
None, since this is consistent with current practice.
Cost to Users:
None, since this is consistent with current practice.
Benefits:
This clarification will assist users in writing portable code.
Aesthetics:
The standard would be less clean were the allowed ranges of its functions not
specified.
Discussion:
There is a separate cleanup proposal RANGE-OF-START-END-PARAMETERS which
addresses a possible incompatible change. This proposal contains what we
think are non-controversial clarifications.
----- End Forwarded Messages -----
∂06-Oct-88 1921 X3J13-mailer Issue: CONTAGION-ON-NUMERICAL-COMPARISONS (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 19:21:12 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 19:18:51 PDT
Date: 6 Oct 88 19:18 PDT
From: masinter.pa@Xerox.COM
to: X3J13@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Subject: Issue: CONTAGION-ON-NUMERICAL-COMPARISONS (version 1)
reply-to: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <881006-191851-1973@Xerox>
!
Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
References: CLtL p.194
Category: CHANGE
Edit history: Version 1, 14-Sep-88, Moon
Problem description:
The numerical contagion rules specified on CLtL p.194 make it impossible
for the numerical comparison functions to be transitive when given
arguments of mixed floating and rational types (see example below).
Proposal (CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE):
Instead of using the same contagion rule both for combining functions
and for comparing functions, make the present rule apply only to
combining functions and add the following rule: When rational and
floating-point numbers are compared by a numerical function, the
function RATIONAL is called to convert the floating-point number to a
rational and then an exact comparison is performed. In the case of
complex numbers (RATIONAL is for some unknown reason only allowed on
reals), the real and imaginary parts are handled individually.
It is of course valid to use a more efficient implementation than
actually calling RATIONAL, as long as the result of the comparison is
the same.
Test Cases/Examples:
(defvar a (/ 10.0 single-float-epsilon))
(= a (1+ (floor a)))
should be NIL, since
(= a (floor a))
is certainly T and
(= (floor a) (1+ (floor a)))
is certainly NIL. However, by the rule of floating-point contagion,
(= a (1+ (floor a)))
is the same as
(= a (float (1+ (floor a)) a))
and the latter form is certainly T.
To understand this example better, it helps to realize that
(= a (+ a 1.0))
is always true, by the definition of single-float-epsilon.
Here is a second example:
(defvar i (floor a))
(<= a (+ i 1)) is T.
(< (+ i 1) (+ i 2)) is T.
(<= (+ i 2) a) is T by CLtL, NIL by this proposal.
Thus CLtL requires
a <= i+1 < i+2 <= a
which ought to imply
a < a
which is absurd.
Rationale:
Transitivity of = and of < are important to many algorithms. What CLtL
says now was probably not intentional, but just the result of thinking
that comparing and combining could be lumped together without really
thinking about it.
Without this change, it is impossible to extend the :TEST argument to
MAKE-HASH-TABLE to allow = or EQUALP, since there could be two table
entries with rational keys that are not =, then GETHASH could be
presented with a floating-point argument that is = to both keys.
Current practice:
Lucid is said to implement the proposal. As far as I know all other
implementations do what CLtL currently says.
Cost to Implementors:
This requires a change in what is likely to be intricate and
implementation-dependent code. However, the total effort should
be small compared to the cost of writing that code originally.
Cost to Users:
This is an incompatible change. It's difficult to know if any users
are depending on the current behavior. It seems likely that most users
would expect the proposed behavior, and may be wondering why their
programs don't quite work when the numbers get large.
Cost of non-adoption:
Comparison functions in Common Lisp will be non-transitive.
Benefits:
Comparison functions in Common Lisp will be transitive.
Esthetics:
Having two rules of floating-point contagion may seem less esthetic,
but I'm certain that having the comparison functions behave in a more
mathematically correct fashion outweighs that esthetically.
Discussion:
Everyone who has expressed an opinion has thought this was the right
thing for years, but we never got around to writing it up as a cleanup
proposal.
----- End Forwarded Messages -----
∂06-Oct-88 2007 X3J13-mailer Issue: DECLARE-TYPE-FREE (Version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Oct 88 20:06:49 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472330; Thu 6-Oct-88 23:05:17 EDT
Date: Thu, 6 Oct 88 23:05 EDT
From: Masinter.PA@Xerox.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Reply-To: CL-Cleanup@SAIL.Stanford.EDU
Subject: Issue: DECLARE-TYPE-FREE (Version 6)
To: X3J13@SAIL.Stanford.EDU
Message-ID: <881006230506.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Issue: DECLARE-TYPE-FREE
References: CLtL p.158
DECLARATION-SCOPE
Category: CLARIFICATION/ADDITION
Edit history: Version 1, 18-Sep-88, Moon
Version 2, 22-Sep-88, Moon
(small edits to reflect mail discussion)
Version 3, 22-Sep-88, Masinter
Version 4, 27-Sep-88, JonL
Version 5, 30-Sep-88, Masinter (cost to implementors)
Version 6, 06-Oct-88, Pitman (minor edits in Discussion)
Problem description:
Section 9.2 of CLtL, p158, says that a declaration specifier like
(TYPE type var1 var2 ...) "... affects only variable bindings".
Since declarations can occur in contexts other than establishing
"variable bindings", most people interpret this statement to mean
that type declarations not in such context are either (1) completely
to be ignored, or (2) invalid CL syntax. Thus both of the following
forms would be suspect in that the type declarations could not have
any effect:
(if (and (typep x 'fixnum) (typep y 'fixnum))
(locally (declare (fixnum x y)) ;LOCALLY does not bind
...algorithm using x and y...) ; any variables.
...similar algorithm using x and y...)
(let ((y 'foo))
(setq y 10)
(let ((x 5)) ;'y' is not being bound in
(declare (fixnum y)) ; this particular context.
(incf y)
...random algorithm...))
Proposal (DECLARE-TYPE-FREE:ALLOW):
Avoid the phrase "affects only variable bindings". Clarify that a type
declaration means that it is an error for the value of the variable not
to be a member of the declared type, within the scope of the declaration.
Clarify that the above programs are valid, and that this kind of
declaration means the same thing as wrapping a THE form around every
reference to the variable, including modifying references by setq or
setf.
Clarify that if nested type declarations refer to the same variable, then
the value of the variable must be a member of the intersection of the
declared types.
Rationale:
It enables optimizing compilers to make use of the otherwise ignored
type information. Many people have often asked for it, and there is
no strong reason to forbid it.
Current practice:
Lucid implements DECLARE-TYPE-FREE:ALLOW already; but under some
circumstances the compiler issues a warning message that such usage
is an extension to Common Lisp.
Cost to Implementors:
Implementations that might currently warn about such declarations
would have to remove the warning; otherwise, it is valid to ignore
type declarations.
Cost to Users:
None, this is a compatible addition.
Cost of non-adoption:
Common Lisp will be less self-consistent.
Benefits:
Programmers will be able to use type declaration to express their
intent, rather than having to manually insert THE wrappers around
every reference.
Esthetics:
It is a simpler interpretation for type declaration specifiers, with
fewer special cases; hence reduces the number of exceptions in the
language.
Discussion:
Another cleanup issue, DECLARATION-SCOPE, addresses the scope of
declarations. This proposal carefully uses the phrase "within the
scope of the declaration" to avoid confounding the two issues.
This issue has been discussed at the Fort Collins X3J13 meeting in
November 1987, and at length on the various electronic mailing lists.
At least one current implementation is able to generate more efficient
code when declarations are associated with a particular binding, since
it then has the option to choose type-specific specialized storage for
the runtime value of the variable. So, for example,
(let ((x v)) (declare (type float x)) (+ x x))
is sometimes more efficient than
(let ((x v)) (locally (declare (type float x)) (+ x x)))
However, the local type declarations allowed by this proposal do
provide some useful information, even if it is not the *most* useful.
It is possible for a sufficiently "smart" compiler to infer the
equivalent of a "binding declaration" when it can ascertain that the
type of the binding value -- 'v' above -- is commensurate with the
type locally declared over the scope of usage of the variable.
It may be useful for a compiler to issue a warning whenever it finds
nested type declarations referring to the same variable and the
intersection of the declared types is null.
Documentation might want to discuss the style implications of
nested declarations intersecting. The interesting cases are:
- An inner declaration could be a subtype of an outer one.
This is the most useful case and probably the only one to
be encouraged in code written by humans. e.g.,
(locally (declare (type number x))
(locally (declare (type integer x))
...use X as integer...))
- An outer declaration could be a subtype of an inner one.
This is useless but harmless. It might happen as the result
of certain macro situations. e.g.,
(locally (declare (type integer x))
(locally (declare (type number x))
...use X as integer...))
- Two types may only partially overlap. This would presumably
happen only as the result of a macro expansion.
(locally (declare (type fixnum x))
(locally (declare (type (or bit package) x))
...use X as BIT...))
∂06-Oct-88 2058 X3J13-mailer Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 20:57:57 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 19:40:12 PDT
Date: 6 Oct 88 19:40 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 2)
To: x3j13@SAIL.STANFORD.EDU
REPLY-TO: CL-CLEANUP@Sail.stanford.edu
line-fold: NO
Message-ID: <881006-194012-2001@Xerox>
!
Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT
References: DECODE-UNIVERSAL-TIME (p445)
Category: CLARIFICATION
Edit history: 20-Jun-88, Version 1 by Pitman
30-Sep-88, Version 2 by Masinter
Problem Description:
The description of DECODE-UNIVERSAL-TIME does not say what happens with
TIME-ZONE. Since the description of ENCODE-UNIVERSAL-TIME mentions that
its behavior differs depending on whether a time zone is explicitly passed,
some implementors may have assumed that DECODE-UNIVERSAL-TIME should do
likewise.
Even if all implementations did the same thing, it should still be clarified
whether an implementation were permitted to return dsp=NIL tz=n rather than
dsp=T tz=n+1 for time zones in which daylight savings time was believed to
be (or known to be) in effect. Currently, you cannot tell whether "NIL" for
daylight-savings-time-p means "daylight savings time is in effect" or
just "daylight savings time is not known to not be in effect".
These tools appear to be more portable than they are.
Proposal (DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE):
Specify that, like ENCODE-UNIVERSAL-TIME, DECODE-UNIVERSAL-TIME ignores
daylight savings information if a timezone is explicitly specified.
Rationale:
This makes things consistent with ENCODE-UNIVERSAL-TIME.
Test Case:
;; ### This test case relies on time zone not changing in real
;; ### time, in defiance of warning in note at bottom
;; ### of p445.
(LET* ((HERE (NTH 8 (MULTIPLE-VALUE-LIST (GET-DECODED-TIME)))) ;Time zone
(RECENTLY (GET-UNIVERSAL-TIME))
(A (NTHCDR 7 (MULTIPLE-VALUE-LIST (DECODE-UNIVERSAL-TIME RECENTLY))))
(B (NTHCDR 7 (MULTIPLE-VALUE-LIST (DECODE-UNIVERSAL-TIME RECENTLY HERE)))))
(LIST A B (EQUAL A B)))
Under this proposal, this would return ((T 5) (NIL 5) NIL) in EDT, for example.
Current Practice:
Symbolics Genera, Symbolics Cloe, Lucid 3.0 and Envos Medley seem to
implement this proposal. Some other implementations do not.
Cost to Implementors:
The cost of changing this should be trivial.
Cost to Users:
This feature is already not well-defined since no portable program can rely
on the current behavior, so the cost is small.
Cost of Non-Adoption:
The time primitives are considerably less useful if this point is not
clearly spelled out.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
Anything that improves the intelligibility of language primitives improves
language aesthetics.
Discussion:
An alternative would be to specify that, unlike ENCODE-UNIVERSAL-TIME,
DECODE-UNIVERSAL-TIME treats daylight savings information the same
regardless of whether a time zone argument is explicitly or not. This seems
actually to be what was intended originally.
This problem arose while trying to port Macsyma between different
Common Lisp implementations. The cleanup committee does not have
a strong opinion on this matter, as long as the behavior is specified.
∂06-Oct-88 2058 X3J13-mailer Issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE, version 2
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 20:58:20 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 20:16:51 PDT
Date: 6 Oct 88 20:16 PDT
From: masinter.pa@Xerox.COM
Subject: Issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE, version 2
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881006-201651-2055@Xerox>
!
Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
References: CLtL p. 312-314
Category: CLARIFICATION
Edit History: V1, 5 Aug 1988, Sandra Loosemore
V2, 15 Sep 1988, Sandra Loosemore
Problem Description:
CLtL doesn't make clear whether defstructs that :INCLUDE another
structure type and do not specify a :PRINT-FUNCTION inherit the
:PRINT-FUNCTION of the parent structure type. While it is stated on
page 314 that #S syntax is used if a :PRINT-FUNCTION is not specified,
the language on page 313 indicates that all operations on the parent
type will also work on objects of the child type. Because of the
ambiguity, existing implementations have gone both ways, and users
cannot depend on either #S syntax or the parent type's :PRINT-FUNCTION
being used.
Proposal: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Clarify that defstruct types which :INCLUDE another type but do not
specify an explicit :PRINT-FUNCTION inherit the structure print
function from the :INCLUDE'd type. A print function that uses the
default #S syntax (overriding any print function for the parent type)
can be specified by providing the :PRINT-FUNCTION option without an
argument.
Rationale:
Users typically specify a print function for a structure type because
its slots will contain circular objects or large internal data
structures which are confusing when printed. Any structure type that
:INCLUDEs this type will also contain the same slots; it seems more
reasonable to inherit the parent's print function than to use the
default #S syntax.
Implementations may wish to use something like CLOS' DEFMETHOD to
implement structure printing, and such methods will naturally be
inherited from the :INCLUDE'd type.
Current Practice:
Lucid Common Lisp makes structures inherit print functions, as do both
Symbolics Genera and Cloe. VaxLisp uses #S syntax unless an explicit
:PRINT-FUNCTION is specified.
Cost to implementors:
The changes to non-conforming implementations should be fairly minor
and localized.
Cost to users:
It can't be any worse than the status quo.
Benefits:
An area of ambiguity in the language will be removed.
Discussion:
Pitman and VanRoggen support this proposal.
The original version of the proposal did not provide for a way to
force #S syntax to be used. This functionality was added to the
current version because there seemed to be general agreement that it
would be useful. Other alternatives would be to name the function
that does what the #S printer does, or to provide a function that
returns the #S information as a list (as suggested by Waters) so users
can write their own.
-------
----- End Forwarded Messages -----
∂06-Oct-88 2058 X3J13-mailer Issue: EXPT-RATIO (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 20:58:36 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 20:49:35 PDT
Date: 6 Oct 88 20:49 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: EXPT-RATIO (Version 2)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881006-204935-2100@Xerox>
!
Issue: EXPT-RATIO
References: CLtL pages 204 and 211
Category: CLARIFICATION
Edit history: Version 1, 4-Oct-88, by Aspinall and Moon
Version 2, 6-Oct-88, Masinter (very minor discussion)
Problem description:
The comment (page 204, 2nd para) that "... an implementation [of expt]
might choose to compute (expt x 3/2) as if it had been written
(sqrt (expt x 3) 2)" disagrees with the principal value definition on
page 211. See the example below for a case where the two disagree. We
believe the principal value definitions are consistent and reasonable,
therefore the implementation comment is wrong.
Proposal (EXPT-RATIO:211):
Clarify that (sqrt (expt x 3) 2) is not equivalent to (expt x 3/2)
and that page 211 rules.
Test Cases/Examples:
(defvar x (exp (/ (* 2 pi #c(0 1)) 3))) ;exp(2.pi.i/3)
(expt x 3) => 1 (except for round-off error)
(sqrt (expt x 3)) => 1 (except for round-off error)
(expt x 3/2) => -1 (except for round-off error)
There can be no question that
(expt x 3) ==> 1
because expt is single-valued with an integer second argument, and
(sqrt 1) ==> 1
definitely follows the principal branch of the square root function.
But (expt x 3/2) is defined as (exp (* (log x) 3/2)) (page 211).
(log x) ==> 2.pi.i/3
according to the definition of the logarithm's branch cuts on page 211
(which really comes down to the branch cuts of phase - page 210), so
(* (log x) 3/2) ==> pi.i
and
exp(pi.i) is -1.
Rationale:
We believe the principal value definitions are consistent and
reasonable, therefore the implementation comment is wrong.
Current practice:
Symbolics Genera 7.3 currently returns the wrong answer, following page
204 rather than page 211. Lucid Common Lisp, and
Envos Medley implement the proposal.
Cost to Implementors:
The obvious code changes in complex expt.
Cost to Users:
None.
Cost of non-adoption:
Self-contradictory language specification.
Benefits:
Users can better predict the branch cuts in expt.
Discussion:
Mathematical Explanation: When the expt function returns a complex result
in CL (Cartesian) form, the phase of the complex number is effectively
canonicalized. Information is lost, and that information is necessary to
specify upon which branch of the sqrt function the final result should lie.
Another way to put it would be that although
sqrt(expt(x,3)) = expt(x,3/2)
where expt and sqrt are the mathematical multi-valued functions, it is not
true that:
pvsqrt(pvexpt(x,3)) = pvexpt(x,3/2)
where pvexpt and pvsqrt denote the principal value versions of those functions.
∂06-Oct-88 2111 X3J13-mailer Issue FIXNUM-NON-PORTABLE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 21:11:32 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 21:08:51 PDT
Date: 6 Oct 88 21:08 PDT
From: masinter.pa@Xerox.COM
Subject: Issue FIXNUM-NON-PORTABLE (Version 3)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881006-210851-2113@Xerox>
!
Issue: FIXNUM-NON-PORTABLE
References: CLtL p. 14, 34, 43, 231
Category: CHANGE, CLARIFICATION
Edit History: Version 1, 11-Jul-88 (Sandra Loosemore)
Version 2, 15-Sep-88, Masinter
Version 3, 23-Sep-88, Masinter
Problem Description:
Implementations of Common Lisp are required to support two disjoint
subsets of integers, fixnums and bignums, with the promise that
fixnums have a more efficient representation. However, nothing is
guaranteed about the range of integers which are fixnums: "Exactly
which integers are fixnums is implementation-dependent; typically they
will be those integers in the range -2**n to 2**n - 1, inclusive, for
some n not less than 15."
There are few uses of the fixnum type that are portable, given the
current definition. In particular, many programmers use FIXNUM type
declarations where they really mean "small integer".
While most Common Lisp implementations have a FIXNUM range
which is a subset of integers represeted and operated on most
efficiently, many also have several other subranges. The
partitioning of INTEGER into BIGNUM and FIXNUM is merely
confusing in these implementations, and not useful.
Proposal: FIXNUM-NONPORTABLE:TIGHTEN-DEFINITION
(1) Change the description of the type FIXNUM to reflect that it is
required to be a supertype of (SIGNED-BYTE 16).
(2) remove the type BIGNUM from the language.
Rationale:
Many programmers already use FIXNUM to mean "small integer"; this
proposal makes this usage portable.
However, there is little portable use for the type BIGNUM, and it
is inconsistent with many current implementation techniques.
Current Practice:
Xerox Common Lisp has 17-bit fixnums. Most other Common Lisp
implementations have fixnum ranges of 24 bits or larger. We know
of no implementation that currently violates the proposed minimum
size.
Several existing Common Lisp implementations have more than two
representations for integers, such that the FIXNUM/BIGNUM distinction
is confusing.
Cost to implementors:
Slight. All implementations we know of already define FIXNUMs to be at
least 16 bits and would only have to remove the BIGNUM type specifier
to be in compliance with the proposal.
Cost to users:
Slight. The removal of the BIGNUM type specifier will affect user code
but it appears to be little-used.
Benefits:
The FIXNUM type specifier would have a portable interpretation.
The language would be less confusing.
Discussion:
Earlier discussion of a related proposal contained several other more controversial
components (adding a constant MAX-INTEGER-LENGTH, allowing
MOST-POSITIVE-FIXNUM to be NIL as well as an integer.) This proposal
is an attempt to address the part that cleanup committee seemed to agree on.
It is possible that an implementation have a single representation for all
integers, and no way to identify any efficient range of integers. Those
implementations might need to set MOST-POSITIVE-FIXNUM
and MOST-NEGATIVE-FIXNUM to arbitrary values, consistent with
the requirement that (SIGNED-BYTE 16) is a subtype of FIXNUM.
Other alternatives considered (and not necessarly mutually exclusive
with this proposal):
remove the FIXNUM type specifier entirely, while leaving a way
to query what is the most efficient range of integers
leave the range of FIXNUMs unconstrained and introduce a
SMALL-INTEGER type with a fixed range (but no promises about
efficiency) .
guarantee that the value of the constant ARRAY-TOTAL-SIZE-LIMIT be a
fixnum (for efficient array addressing)
It might be possible to specify the required performance behavior
of FIXNUMs more concretely, e.g., specify that the basic integer operations
use algorithms that are not proportional to the size of the data; it
should be just about as fast to add numbers in the middle of the fixnum
range as it is to add, say, 10 and 11. This might be a useful way to describe
the intent of the FIXNUM range, if not its specification.
∂06-Oct-88 2123 X3J13-mailer Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 21:23:24 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 21:20:45 PDT
Date: 6 Oct 88 21:20 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881006-212045-2149@Xerox>
!
Issue: FORMAT-E-EXPONENT-SIGN
References: CLtL pp. 366, 393
Category: CLARIFICATION
Edit history: Bob Cassels, 13 Sep 88
Masinter, 2-Oct-88 (change issue name)
Related issues: <none>
Problem description:
The result of (format nil "~E" 1.0) is specified in a contradictory way.
The ambiguity is whether a plus sign should be printed in front of
the exponent.
The top of page 393 says, "Next, either a plus or a minus sign is
printed, followed by e digits ... [decimal exponent]"
Later on page 393 we see, "If all of w, d, and e are omitted, then the
effect is ... [like prin1].
Page 366 [presumably where prin1 is defined] doesn't explicitly say that
the plus sign is omitted from the exponent, but all the examples (and
usual practice) indicate that.
So the posssibilities are:
A. "1.0e+0"
B. "1.0e0"
The first reference implies that A is correct, the third reference
implies that B is correct. The second reference implies that A and B
are the same.
Proposal (FORMAT-E-EXPONENT-SIGN:FORCE-SIGN):
Specify that ~E always prints a plus or minus sign in front of the
exponent.
This would cause the language on page 393 of CLtL to to change:
"If all of w, d, and e are omitted, then the effect is to print the
value using ordinary free-format exponential-notation output; PRIN1 uses
a similar format for any non-zero number whose magnitude is less than
10**-3 or greater than or equal to 10**7. The only difference is that
the ~E directive always prints a plus or minus sign in front of the
exponent, while PRIN1 omits the plus sign if the exponent is
non-negative."
Test Case:
(format nil "~E" 1.0) => "1.0e+0"
Rationale:
This proposal makes ~E self-consistent. That is more important than
making ~E consistent with PRIN1.
Current practice:
Symbolics Common Lisp, Ibuki Lisp, and VAX Lisp all print the plus
sign as in the test case above. Apollo DOMAIN Common Lisp (version
2.10) and Xerox Common Lisp produce "1.0", which is wrong because
it includes no exponent at all.
Adoption Cost:
Minimal changes to one printing routine for non-conforming
implementations. (No change to the three implementations mentioned
above.)
Cost of non-adoption:
Minor confusion and possible incompatibility among implementations.
Benefits:
Less confusion, more compatibility.
Conversion Cost:
Minimal. It is doubtful that any user programs depend on this
obscure distinction.
Esthetics:
A matter of opinion.
Discussion:
Fortran ~E format requires a sign before the exponent, since the exponent
mark character may be dropped. Since Common Lisp ~E always prints
the exponent marker, the exponent sign may be dropped in the case
that it would be a plus sign.
∂06-Oct-88 2150 X3J13-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 21:50:36 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 21:47:56 PDT
Date: 6 Oct 88 21:48 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 4)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881006-214756-2172@Xerox>
Version 2 was distributed at a previous X3J13 meeting.
!
Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
References: CLtL p. 27, 47-48, 61
"Artifical Intelligence Programming", Charniak et. al.
X3J13/86-003 (A:>GLS>clarifications.text.4)
Category: CLARIFICATION, ADDITION
Edit history: Version 1, 23-Nov-1987 Sandra Loosemore
Version 2, 15-Jan-1988 Sandra Loosemore
(incorporate comments from Scott Fahlman & others)
Version 3, 13-Feb-88 Masinter
Version 4, 2-Oct-88 Masinter (update references, discussion)
Related issues: FUNCTION-TYPE-KEY-NAME,
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
REST-LIST-ALLOCATION
Problem description:
The FUNCTION type specifier list is provided to allow declaration of function argument types and return value types. This type specifier uses a syntax similar to the usual lambda list syntax to specify which types go with which lambda list variables. However, this is actually of limited usefulness in the context of a declaration, where one normally wants type information about the actual arguments which can be passed to the function rather than the lambda variables to which they are bound.
There is a particular problem with &REST lambda variables, which are always bound to a value of type LIST. For the sake of consistency, it would seem that the corresponding type given in the FUNCTION declaration must also be LIST, but since this provides no information about the actual arguments, some users/implementors have instead adopted the convention of supplying the type of the actual arguments which are gathered into the list.
CLtL is vague on the issue, mentioning only that &REST may appear in the type specifier without touching upon its interpretation.
Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE):
Clarify that, in the FUNCTION type specifier, the type specifier provided with &REST is the type of each actual argument, not the type of the corresponding lambda variable.
Example:
The type of the function + would be specified as:
(FUNCTION (&REST NUMBER) NUMBER)
Rationale:
This is more useful than specifying that the type of a &REST parameter must be LIST, since it provides information about the actual arguments.
Current practice:
There does not appear to be any concensus on this issue. Most Common Lisp implementations currently ignore FUNCTION type declarations. The only examples found so far are in a text book on Common Lisp, which follows the proposed syntax.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier may continue to do so. Probably only a small amount of code would have to be written/changed in implementations that currently think that the &REST argument should be LIST.
Cost to Users:
Users who have been using the convention that the &REST type parameter must be LIST will have to change their code. However, because this issue is so unclear, the FUNCTION type specifier is probably not used very much.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of limited use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language design.
Esthetics:
Debatable. One the one hand, since the argument type syntax used by the FUNCTION type specifier mirrors normal lambda-list syntax, it would be cleaner and less confusing to provide the type of the lambda variable rather than the type of the actual arguments. However, considering the types specified in the FUNCTION specifier to be the types of the actual arguments rather than the types of the parameters as seen on the receiving end makes the proposed semantics more palatable.
Discussion:
This issue provoked considerable debate in the cleanup committee and at X3J13. It seems like a vote on LIST-TYPE-SPECIFIER would help clarify some of the issues; if there is a LIST type specifier, there would be more support for the alternative proposal to require that the &REST argument declaration, if any, always be LIST or a subtype of LIST, and to extend the LIST type to allow declarations of the form, e.g., (LIST NUMBER).
Those who favor USE-ACTUAL-ARGUMENT-TYPE argue that the simplicity of the declarations and the ugliness of the alternative, as well as the weight of current practice, argue for it.
Kent Pitman has argued against this proposal on the following grounds:
``* It is bothersome that the same argument declarations which are used internally in the function would not be be usable externally.
``* It is unfair to provide only this special-purpose way of declaring a sequence type when in fact there are numerous other places in the language where it might be useful to declare a sequence type.
``If we did go with USE-ACTUAL-ARGUMENT-TYPE, it should be stated explicitly (if it is not already in CLtL somewhere) that the following is illegal:
(DEFUN FOO (&REST X) X)
(APPLY #'FOO T)
since there will be no way to type-declare this. Even though this is an obscure case (that doesn't even work in some implementations), it's the sort of thing that makes me queasy about USE-ACTUAL-ARGUMENT-TYPE.''
∂07-Oct-88 0052 tah@linz Reminder: MTC Seminar
Received: from linz.stanford.edu by SAIL.Stanford.EDU with TCP; 7 Oct 88 00:52:49 PDT
Received: by linz.stanford.edu (4.0/SMI-DDN)
id AA14553; Fri, 7 Oct 88 00:49:41 PDT
Message-Id: <8810070749.AA14553@linz.stanford.edu>
To: alur@polya, arean@polya, barwise@russell, bhoward@polya, chavez@sumex-aim,
clt@sail, coraki!pratt@sun.com, crew@polya, devlin@csli, dill@amadeus,
eswolf@polya, fernando@csli, galbiati@polya, grove@polya,
gurevich@polya, herskovits@sumex-aim, hirani@sun.com, howard@polya,
jcm@ra, jmc-lists@sail, kar@polya, kolaitis@polya, lincoln@polya,
lowry@coyote, ma@src.dec.com, martin@polya, mb@jeeves, mcguire@polya,
shankar@score, olthoff@hplabs.hp.com, peters@russell, pieper@geode,
polaschek@sumex-aim, rdz@score, rjw@sail, roach@score, rtc@sail,
sf@csli, traugott@jeeves, val@sail, vardi@polya, vasilis@polya,
weening@gang-of-four, zm@sail, tah@linz
Cc: csd@score, new-phd@polya
Subject: Reminder: MTC Seminar
Date: 07 Oct 88 00:49:35 PDT (Fri)
From: Tom Henzinger <tah@linz>
There will be an organizational meeting today, Friday Oct. 7, at 12:00 noon
in MJH 252. We'll decide on form and contents of the seminar; any suggestions
are welcome. Feel free to bring your lunch.
-- Tom.
∂06-Oct-88 2057 X3J13-mailer Issue: DECLARE-FUNCTION-AMBIGUITY (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 20:57:36 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 19:30:02 PDT
Date: 6 Oct 88 19:30 PDT
From: masinter.pa@Xerox.COM
to: X3J13@sail.stanford.edu
REPLY-TO: CL-CLEANUP@sail.stanford.edu
Subject: Issue: DECLARE-FUNCTION-AMBIGUITY (version 3)
Message-ID: <881006-193002-1990@Xerox>
Issue: DECLARE-FUNCTION-AMBIGUITY
References: CLtL pp 43 (Table 4-1), 158-159
Issue FUNCTION-TYPE (passed X3J13/June 1988)
Category: CHANGE
Edit history: #1, 21 Sept 1988, Walter van Roggen
#2, 29 Sept 1988, Walter van Roggen (renamed; lessened ambiguity)
#3, 30-Sep-88, Masinter
Problem description:
CLtL permits confusing and ambiguous FUNCTION declarations. One can say
(DECLARE (FUNCTION F (VECTOR INTEGER) T))
to indicate that the function binding for F is of a certain type. Yet
one can also say
(DECLARE (FUNCTION X Y Z))
to indicate that the variables X, Y, and Z have values which are functions.
The former is an abbreviation for
(DECLARE (FTYPE (FUNCTION (VECTOR INTEGER) T) F))
The latter is an abbreviation for
(DECLARE (TYPE FUNCTION X Y Z))
The ambiguity arises in a case like
(DECLARE (FUNCTION F NIL STRING))
However, it would be an error to declare the type of the constant NIL to be a
FUNCTION, so technically there is no ambiguity--there is just a peculiar
special case.
Using the same declaration for two completely different purposes can lead
to confusion among people writing or reading such code.
It is now more useful to declare that variables have a value which
is of type FUNCTION, since the type FUNCTION has a more well-specified
meaning.
Proposal (DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION)
The declaration (FUNCTION name argtypes valtypes) is no longer permitted
to be an abbreviation for (FTYPE (FUNCTION argtypes valtypes) name).
The declaration (FUNCTION var1 var2) would just be an abbreviation for
(TYPE FUNCTION var1 var2).
Rationale:
Continuing to allow all the predefined atomic type specifiers as declaration
abbreviations for (TYPE type var1 var2 ...) is simpler for users to understand.
In other words, all the normal type declarations describe variable bindings;
only the FTYPE declaration describes function bindings. This is a more
uniform solution than making an exception to table 4-1.
Since the old use of the FUNCTION declaration for function bindings was just
an abbreviation for the FTYPE declaration, no expressivity is lost.
Furthermore one is able to say that a variable's value is of type FUNCTION,
something that hadn't been clearly possible without using the TYPE declaration.
Current Practice:
Many current implementations treat FUNCTION declarations
only as abbreviations for FTYPE declarations, primarily because
the proposal FUNCTION-TYPE has not been widely implemented.
Cost to Implementors:
Likely to be small to those implementations that heed these kinds of
declarations; none for those that don't.
Cost to Users:
Existing uses of the FUNCTION declaration for function bindings will need
to be changed to FTYPE declarations.
Cost of Non-Adoption:
People will continue to be confused by function declarations.
Benefits:
A simpler language.
Esthetics:
Discussion:
Making it clear that only FTYPE declarations describe function bindings will
make it easier to add new kinds of declarations that support incremental or
additional descriptions, as is needed for describing methods.
Since all cases can be disambiguated after all, compatibility considerations
might deem this proposal to be unnecessary. However, making declarations
simpler and less confusing is possibly more important than compatibility.
There is no consensus on the cleanup committee.
∂06-Oct-88 2058 X3J13-mailer Re: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 20:58:09 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 20:12:18 PDT
Date: 6 Oct 88 20:12 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
to: x3J13@sail.stanford.edu
cc: masinter.pa@Xerox.COM
REPLY-TO: Cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <881006-201218-2044@Xerox>
apologies if you get this twice; more mailer problems...
!
Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
References: CLtL page 316
Category: CHANGE
Edit history: 20-Sep-88, Version 1, Peck
21-Sep-88, Version 2, Masinter, minor revisions
Problem description:
Currently, defstruct constructor functions can be either the default
constructor function, with *only* keyword arguments, or it can be a
so-called "By Order of Arguments" constructor function with explicitly
*no* keyword arguments. Other functions in Common Lisp allow a free
mix of required, optional, and keyword arguments.
With the current restriction, it is necessary to hand code a function that
will accept optional and keyword arguments and parse the supplied-p
variables explicitly. Even so, it is not obvious to the casual programmer
how to provide the same semantics as defstruct does with respect to default
values and the defstruct init-forms.
Proposal: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Allow combination of &OPTIONAL, &KEY and &AUX arguments in
constructor forms of defstructs.
The current wording in CLtL (p314):
"In addition, the keywords &optional, &rest, and &aux are recognised
in the argument list. They work in the way you might expect ..."
would be extended accordingly.
Example:
It should be possible to write forms like this:
(defstruct (foo (:constructor CREATE-FOO (a &optional b (c 'sea)
&key (d 2)
&aux e (f 'eff))))
(a 1) (b 2) (c 3) (d 4) (e 5) (f 6))
(create-foo 10) => #S(foo a 10 b 2 c sea d 2 e nil f eff)
(create-foo 10 'bee 'see :d 'dee) => #S(foo a 10 b bee c see d dee e nil f eff)
Rationale:
This is a logical extension of the specification which makes some
programming easier.
Current practice:
Some implementations to signal an error. Envos Medley (Xerox Common Lisp)
implements the proposed behavior.
Cost to Implementors:
The modifications to allow intermixed keywords and optionals in implementations
that don't already are likely simple.
Cost to Users:
No cost, this is upward compatible.
Cost of non-adoption:
The current situation is non-intuitive and needless restrictive.
Benefits:
Much easier for users to write the constructor function they want.
Probably implementation code would be reduced, since this would no
longer be an error.
Esthetics:
Minor improvement since it removes a needless restriction.
Discussion:
Possibly references to "By-position", "positional", and "By Order of
Arguments" constructor function might need to be changed to something else in
the standard. (They can still be called BOA-constructors, though, right? :-)
∂07-Oct-88 0743 CL-Cleanup-mailer Issue FIXNUM-NON-PORTABLE (Version 3)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 07:43:06 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Fri, 7 Oct 88 10:42:59 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 7 Oct 88 10:39:56 EDT
Date: Fri, 7 Oct 88 10:40 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Issue FIXNUM-NON-PORTABLE (Version 3)
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu, Masinter.pa@xerox.com
In-Reply-To: <881006-210851-2113@Xerox>
Message-Id: <19881007144039.0.BARMAR@OCCAM.THINK.COM>
Date: 6 Oct 88 21:08 PDT
From: masinter.pa@xerox.com
Proposal: FIXNUM-NONPORTABLE:TIGHTEN-DEFINITION
(2) remove the type BIGNUM from the language.
I don't really see the point of this. Isn't BIGNUM simply defined to be
(AND INTEGER (NOT FIXNUM))? I admit that it isn't an extremely useful
type specifier, but it is just as portable as FIXNUM.
barmar
∂07-Oct-88 0804 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu PODS-89 Symposium - Address for express delivery carriers
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Oct 88 08:04:32 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA03393; Fri, 7 Oct 88 08:02:57 PDT
Message-Id: <8810071502.AA03393@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 7 Oct 88 08:03:43 PDT
Received: by BYUADMIN (Mailer X1.25) id 8197; Fri, 07 Oct 88 09:01:16 MDT
Date: Fri, 7 Oct 88 09:47:02 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Ashok K. Chandra" <ashok@IBM.COM>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Ashok K. Chandra" <ashok@IBM.COM>
Subject: PODS-89 Symposium - Address for express delivery carriers
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
The IBM T. J. Watson Research Center uses a P.O. Box address. However,
express delivery companies such as Airborne, Federal Express, UPS etc.
do not normally deliver to P.O. Boxes (the US Mail will deliver to
P.O. Boxes with its Express Mail service). When using express delivery
carriers, the address
IBM T. J. Watson Research Center
P.O. Box 218
Yorktown Heights, NY 10598
can be replaced by:
IBM T. J. Watson Research Center
Route 134 and Kitchawan Road
Yorktown Heights, NY 10598.
This may be used, for example, when submitting abstracts for the
8th PODS symposium - a copy of the call is attached.
-------------------------
Call for Papers
Eighth ACM SIGACT-SIGMOD-SIGART Symposium on
PRINCIPLES OF DATABASE SYSTEMS (PODS)
Philadelphia, Pennsylvania, March 29-31, 1989
Extended Abstracts due October 10, 1988
The conference will cover new developments in both the theoretical and
practical aspects of database and knowledge-base systems. Papers are
solicited which describe original and novel research about the theory,
design, specification, or implementation of database and knowledge-
base systems.
Some suggested, although not exclusive, topics of interest are:
complex objects, concurrency control, database machines, data models,
data structures, deductive databases, dependency theory, distributed
systems, incomplete information, knowledge representation and
reasoning, object-oriented databases, performance evaluation, physical
and logical design, query languages, query optimization, recursive
rules, spatial and temporal data, statistical databases, and
transaction management.
You are invited to submit eleven copies of a detailed abstract (not a
complete paper) to the program chairman:
Ashok K. Chandra - PODS
IBM T. J. Watson Research Center
P.O. Box 218
Yorktown Heights, NY 10598.
ashok@ibm.com (914) 945-1752.
Submissions will be evaluated on the basis of significance,
originality, and overall quality. Each abstract should 1) contain
enough information to enable the program committee to identify the
main contributions of the work; 2) explain the importance of the work -
its novelty and its practical or theoretical relevance to database
and knowledge-base systems; and 3) include comparisons with and
references to relevant literature. Abstracts should be no longer than
ten double-spaced pages. Deviations from these guidelines may affect
the program committee's evaluation of the paper.
Program Committee
Catriel Beeri Daniel J. Rosenkrantz
Ashok K. Chandra Oded Shmueli
Hector Garcia-Molina Victor Vianu
Michael Kifer William E. Weihl
Teodor C. Przymusinski Carlo Zaniolo
The deadline for submission of abstracts is OCTOBER 10, 1988. Authors
will be notified of acceptance or rejection by December 7, 1988. The
accepted papers, typed on special forms, will be due at the above
address by January 11, 1989. All authors of accepted papers will be
expected to sign copyright release forms. Proceedings will be
distributed at the conference, and will be subsequently available for
purchase through the ACM.
General Chair: Local Arrangements Chair:
Avi Silberschatz Tomasz Imielinski
Computer Science Department Dept. of Computer Science
Univ. of Texas at Austin Rutgers University
Austin, Texas 78712 New Brunswick, NJ 08903
avi@sally.utexas.edu imielinski@rutgers.edu
∂07-Oct-88 0856 @Score.Stanford.EDU:jwilson@jaguar.Stanford.EDU Discussion of the Nox-Sox building
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Oct 88 08:56:49 PDT
Received: from jaguar.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 7 Oct 88 08:49:23-PDT
Received: by jaguar.Stanford.EDU (5.51/inc-1.01)
id AA05297; Fri, 7 Oct 88 08:55:42 PDT
Date: Fri, 7 Oct 88 08:55:42 PDT
From: James Wilson <jwilson@jaguar.Stanford.EDU>
Message-Id: <8810071555.AA05297@jaguar.Stanford.EDU>
To: faculty@score.stanford.edu, staff@score.stanford.edu,
students@score.stanford.edu
Subject: Discussion of the Nox-Sox building
Just a reminder that a bulletin board exists to discuss the new Nox-Sox
building. To submit your comments, send mail to csd-building@polya or
csd-building@score. To read the bulletin board, read the newsgroup csd.building
on Unix machines or type "bboard csd-building" on score.
James Wilson
∂07-Oct-88 0911 @Score.Stanford.EDU:ball@polya.Stanford.EDU CSD-CF Rates for 1988-89
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Oct 88 09:11:40 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 7 Oct 88 09:07:46-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA05715; Fri, 7 Oct 88 09:09:01 PDT
Date: Fri, 7 Oct 88 09:09:01 PDT
From: Jim Ball <ball@polya.Stanford.EDU>
Message-Id: <8810071609.AA05715@polya.Stanford.EDU>
To: Faculty@Score
Cc: Facil@Score
Subject: CSD-CF Rates for 1988-89
The following rates have been sent to the controller's office for
approval. Approval is expected and only minor adjustments may
have to be made. I am sending them to you for planning purposes
only. As soon as the approved rates are available they will be
distributed.
One major change is the job-time or connect time charge. Connect
time was charged at $1.00 per hour for A time, it is now .10 per
hour. Maintaining the connect time charge, even at a low level
helps keep us focused on the fact that much of our attention, and
time goes into the CSD network. Perhaps we can find a better way
of measuring and charging for this resource in the future. CPU and
Disk storage charges were adjusted to compensate for this change
since they represent the real system resources being utilized.
Another change is the fact that printing charges had to be increased
from .09 a page to .10 a page for laser printers and the Dover. Boise
charges were increased from .07 to .09 per page.
-Jim Ball
COMPUTER SCIENCE DEPARTMENT COMPUTER FACILITIES
PROPOSED SERVICE CENTER RATES
9/1/88
TIME WEEKDAY WEEKEND
--------- --------- ---------
"A" RATES = 100% 0000-0800 C C
"B" RATES = 66.67% * "A" RATE 0800-1300 A C
"C" RATES = 33.33% * "A" RATE 1300-1800 A B
1800-2400 B C
--------TIME OF DAY RATES---------
"A" "B" "C" Monthly
---- ---- ---- -----------
Score
Account charge Accts 5.00
Connect time 0.10 0.07 0.03
CPU time Min. 4.25 2.83 1.42
Disk space Mbits/Mo 2.85
Sail
Account charge Accts 5.00
Connect time 0.10 0.07 0.03
CPU time Min. 5.50 3.67 1.83
Disk space Mbits/Mo 2.75
Labrea
Account charge Accts 5.00
Connect time 0.10 0.67 0.33
CPU time Min. 1.25 1.00 0.50
Disk space Mbits/Mo 1.35
Jeeves
Account charge Accts 5.00
Disk space Mbits/Mo 1.08
Polya
Account charge Accts 5.00
Connect time 0.10 0.67 0.33
CPU time Min. 3.00 0.50 0.25
Disk space Mbits/Mo 2.85
Printers
Dovers pages 0.10
Imagen/Apple pages 0.10
Boise pages 0.09
Phototypesetter
Page charges 4.50
Ethernet Maintenance
Monthly charges
Workstations & Minis 33.00
Mainframes & Bridges 330.00
VAX-750 Computer Maint.
Monthly charges
Basic VAX-750 475.00
RA81 Disk Drive 100.00
Kennedy 9300 Tape 200.00
Fujitsu M2351 Disk 50.00
TU78 100.00
CDC 9766 Controller 100.00
Emulex SC758 66.00
8 line term MUX 16.00
∂07-Oct-88 0955 HEMENWAY@Score.Stanford.EDU Meeting Announcement
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Oct 88 09:55:12 PDT
Date: Fri 7 Oct 88 09:51:16-PDT
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Meeting Announcement
To: faculty@Score.Stanford.EDU
Message-ID: <12436557599.16.HEMENWAY@Score.Stanford.EDU>
The Ph.D. Program committee will meet on Monday, Oct. 10, 12-2, in MJH
220 to discuss a number of matters of pressing concern, including
possible revision of the comprehensive exam requirement.
Recommendations resulting from this and future committee meetings will
be presented to the faculty as a whole for discussion and approval.
Interested faculty members who would like to join the discussion at
this stage (and are not on the committee!), are invited to attend.
Sharon
-------
∂07-Oct-88 1042 hoffman@csli.Stanford.EDU First Day of the Forum
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Oct 88 10:42:29 PDT
Received: by csli.Stanford.EDU (4.0/4.7); Fri, 7 Oct 88 10:41:37 PDT
Date: Fri 7 Oct 88 10:41:37-PDT
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: First Day of the Forum
To: ssp-faculty@csli.Stanford.EDU, ssp-students@csli.Stanford.EDU,
ssp-forum@csli.Stanford.EDU
Message-Id: <592249297.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
This is the first day of the forum! Today we are discussing a
wide variety of policy issues for the major and the forum. All
students in SSP who have an interest in SSP and everyone who has
an interest in how the forum will be run should come. In case
my earlier mail got lost, here is a repeat of the directions:
Directions:
The Symbolic Systems Forum meets every friday at 3:15 PM, in rm 62n,
in building 60.
Building 60 is the symbolic systems building. It is the building to
the right side of memorial church (on the inner quad) as one walks into
the inner quad from the oval.
Rm. 62n is the room on the second floor of the building, in the center,
facing in towards the inner quad. It is across from Jon Barwise's and
John Perry's offices.
-------
∂07-Oct-88 1302 @Score.Stanford.EDU:ball@polya.Stanford.EDU [ball@polya.Stanford.EDU: CSD-CF Rates for 1988-89]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Oct 88 13:01:55 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 7 Oct 88 12:58:09-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA22040; Fri, 7 Oct 88 12:59:24 PDT
Date: Fri, 7 Oct 88 12:59:24 PDT
From: Jim Ball <ball@polya.Stanford.EDU>
Message-Id: <8810071959.AA22040@polya.Stanford.EDU>
To: Faculty@Score
Cc: Facil@Score
Subject: [ball@polya.Stanford.EDU: CSD-CF Rates for 1988-89]
A couple of typos were found in the attached memo. The rates for B
& C time on both Labrea and Polya were incorrect.
Sorry for the inconvenience.
-Jim Ball
Return-Path: <@Score.Stanford.EDU:ball@polya.Stanford.EDU>
Date: Fri, 7 Oct 88 09:09:01 PDT
From: Jim Ball <ball@polya.Stanford.EDU>
To: Faculty@Score
Cc: Facil@Score
Subject: CSD-CF Rates for 1988-89
The following rates have been sent to the controller's office for
approval. Approval is expected and only minor adjustments may
have to be made. I am sending them to you for planning purposes
only. As soon as the approved rates are available they will be
distributed.
One major change is the job-time or connect time charge. Connect
time was charged at $1.00 per hour for A time, it is now .10 per
hour. Maintaining the connect time charge, even at a low level
helps keep us focused on the fact that much of our attention, and
time goes into the CSD network. Perhaps we can find a better way
of measuring and charging for this resource in the future. CPU and
Disk storage charges were adjusted to compensate for this change
since they represent the real system resources being utilized.
Another change is the fact that printing charges had to be increased
from .09 a page to .10 a page for laser printers and the Dover. Boise
charges were increased from .07 to .09 per page.
-Jim Ball
COMPUTER SCIENCE DEPARTMENT COMPUTER FACILITIES
PROPOSED SERVICE CENTER RATES
9/1/88
TIME WEEKDAY WEEKEND
--------- --------- ---------
"A" RATES = 100% 0000-0800 C C
"B" RATES = 66.67% * "A" RATE 0800-1300 A C
"C" RATES = 33.33% * "A" RATE 1300-1800 A B
1800-2400 B C
--------TIME OF DAY RATES---------
"A" "B" "C" Monthly
---- ---- ---- -----------
Score
Account charge Accts 5.00
Connect time 0.10 0.07 0.03
CPU time Min. 4.25 2.83 1.42
Disk space Mbits/Mo 2.85
Sail
Account charge Accts 5.00
Connect time 0.10 0.07 0.03
CPU time Min. 5.50 3.67 1.83
Disk space Mbits/Mo 2.75
Labrea
Account charge Accts 5.00
Connect time 0.10 0.67 0.33
CPU time Min. 1.25 0.83 0.42
Disk space Mbits/Mo 1.35
Jeeves
Account charge Accts 5.00
Disk space Mbits/Mo 1.08
Polya
Account charge Accts 5.00
Connect time 0.10 0.67 0.33
CPU time Min. 3.00 2.00 1.00
Disk space Mbits/Mo 2.85
Printers
Dovers pages 0.10
Imagen/Apple pages 0.10
Boise pages 0.09
Phototypesetter
Page charges 4.50
Ethernet Maintenance
Monthly charges
Workstations & Minis 33.00
Mainframes & Bridges 330.00
VAX-750 Computer Maint.
Monthly charges
Basic VAX-750 475.00
RA81 Disk Drive 100.00
Kennedy 9300 Tape 200.00
Fujitsu M2351 Disk 50.00
TU78 100.00
CDC 9766 Controller 100.00
Emulex SC758 66.00
8 line term MUX 16.00
∂07-Oct-88 1501 X3J13-mailer Issue: IN-PACKAGE-FUNCTIONALITY (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 15:01:43 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 OCT 88 14:53:48 PDT
Date: 7 Oct 88 14:53 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: IN-PACKAGE-FUNCTIONALITY (Version 2)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-145348-1132@Xerox>
!
Issue: IN-PACKAGE-FUNCTIONALITY
References: IN-PACKAGE (p183)
Category: CHANGE
Edit history: 07-Jul-88, Version 1 by Pitman
7-Oct-88, Version 2 by Masinter (discussion)
Related-Issues: DEFPACKAGE
Problem Description:
There are two typical uses for IN-PACKAGE -- to define/create a package
and to select a package. The fact that these two purposes have been
given to the same function has led to reduced error checking.
Proposal (IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY):
Eliminate the ability of IN-PACKAGE to create a package on demand.
Require IN-PACKAGE to signal an error if the package does not exist.
Eliminate the :NICKNAMES and :USE arguments to IN-PACKAGE, since they
are no longer needed.
Clarify that DEFPACKAGE is the preferred way to declare a package,
and MAKE-PACKAGE is the preferred way to construct a package at runtime.
Eliminate the compile-time processing requirement for all package-related
functions except IN-PACKAGE and DEFPACKAGE.
Test Case:
#1: (IN-PACKAGE 'NO-SUCH-PACKAGE) ;signals an error
#2: (DEFPACKAGE FOO ...options...) ;defines/creates a package
(IN-PACKAGE 'FOO) ;selects an existing package
Rationale:
This would greatly improve error checking and modularity, with only minimal
loss of functionality. Any call to IN-PACKAGE which really needed to
demand-create a package could be rewritten as a DEFPACKAGE followed by an
IN-PACKAGE.
Current Practice:
Probably no one implements this behavior since it's in direct
contradiction of both the definitions and numerous examples in CLtL.
Cost to Implementors:
This change would be straightforward to implement.
The cost may not be trivial in all cases, but should not be very large.
Cost to Users:
In most cases, minor syntactic changes to some files would be necessary.
In many cases, no changes would be necessary since files may already be
doing IN-PACKAGE in situations where the author is hoping he's made sure
the real package declaration is already loaded.
Cost of Non-Adoption:
Reduced error checking.
Less modular code.
Benefits:
Errors due to demand-creation of a package by IN-PACKAGE without appropriate
uses of the :USE or :NICKNAMES or without appropriate calls to EXPORT, etc.
afterward would be easier to detect.
Modular package declarations would be encouraged.
Aesthetics:
The fact that IN-PACKAGE is currently ambiguous about intent (whether the
package should exist already or not) is clearly not aesthetic. This change
would be an aesthetic improvement.
Discussion:
The cleanup committee supports IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY.
The dual use of IN-PACKAGE has not been helpful and is confusing.
Some members support it only if DEFPACKAGE passes; others would like
to see IN-PACKAGE changed even if DEFPACKAGE were not added to the language.
However, there might be some compilation problems if IN-PACKAGE
changes and MAKE-PACKAGE signals an error if the package exists.
∂07-Oct-88 1501 X3J13-mailer Issue HASH-TABLE-TESTS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 15:01:13 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 14:45:57 PDT
Date: 7 Oct 88 14:45 PDT
From: masinter.pa@Xerox.COM
Subject: Issue HASH-TABLE-TESTS (Version 1)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-144557-1115@Xerox>
!
Issue: HASH-TABLE-TESTS
References: CLtL, p382 (third paragraph), and p383
Issue EQUAL-STRUCTURE
Requires Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
Category: Addition
Edit history: 26-Sep-88 Version 1 by JonL
Problem Description:
A great many users try to coalesce two equivalent defstruct instances,
or two equivalent pointer arrays, using hash tables; but they are rudely
awakened when they find out that EQUAL is not an appropriate test for
this case, and that there is no :test argument to MAKE-HASH-TABLE which
will "hash on non-tree structures".
Proposal: HASH-TABLE-TESTS:ADD-EQUALP
With the advent of the issue CONTAGION-ON-NUMERICAL-COMPARISONS, we
can expect EQUALP to be a true equivalence function, and thus a suitable
candidate for the :test function to MAKE-HASH-TABLE. Hash-tables will
come in four kinds, the difference being whether the keys are compared
with EQ, EQL, EQUAL, or EQUALP.
Examples:
> (defstruct foo a b c)
FOO
> (setq x (make-foo :a 1 :b 'b :c '(1 . 2))
x-copy (make-foo :a 1 :b 'b :c '(1 . 2)))
#S(FOO A 1 B B C (1 . 2))
> (setq y #(1 B (1 . 2))
y-copy (copy-seq y))
#(1 B (1 . 2))
> (setq ht-equal (make-hash-table :test 'equal)
ht-equalp (make-hash-table :test 'equalp))
#<Hash-Table BB1F7B>
> (progn (setf (gethash x ht-equal) t) (setf (gethash x ht-equalp) t)
(setf (gethash y ht-equal) t) (setf (gethash y ht-equalp) t))
T
> (gethash x-copy ht-equal)
NIL
NIL
> (gethash x-copy ht-equalp)
T
T
> (gethash y-copy ht-equal)
NIL
NIL
> (gethash (copy-seq y) ht-equalp)
T
T
>
Rationale:
Implementing hash-tables efficiently is not an easy task; it makes more
sense for this to be standardly available (implemented by the wizards at
the Lisp vendor companies) than for individual programmers to keep trying
to re-invent this obscure part of technology.
Current Practice:
Lucid's release 3.0 implements this proposal [some 2.1-level release
supported it "provisionally"]. Symbolics implementation is reputed
to be robust enough to implement this proposal trivially.
Cost to Implementors:
Moderate. Implementors have already dealt with EQUAL; the only tricky
part will be ensuring the implication:
"If 'a' is EQUALP to 'b', then 'a' and 'b' must lie in the
same collision chain in any given EQUALP hash table"
It has been suggested that merely linear searching a table is an acceptable
implementation technique for CL's hash-tables [although no serious
implementation limits itself thus] and that such tables have no "collision
chains"; but in fact, this is the degenerate case wherein all entries are
in the same collision chain, so the implication is trivially satisfied.
Some persons prefer to say that the "reprobe sequence will be the same for
the two items", rather than using the term "collision chain"; the meaning
is the same.
Cost to Users:
None. This is an entirely upwards-compatible addition.
Cost of non-adoption:
Continuing bug reports from CL vendors' customers about why "hashing
doesn't work" when said customer tries entering pointer-containing objects
other than cons cells into hash tables. Continuing delay in same
customers work until they figure out a new strategy for identifying
equivalent structures. More difficulty in debugging their alternatives.
Benefits:
Addresses one aspect of the difficult equivalence problem. Makes
hash tables usable with the major, remaining equivalence predicate
of CL. Also as a "side effect", permits case-insensitive hashing
on strings [tables of type EQUAL are case-sensitive on strings];
another "side effect" is the abililty to use the CL numeric comparison
"=" for numbers [tables of type EQUAL use EQL on numbers].
Aesthetics:
Reduces the discontinuity between basic equivalence functions and those
usable as equivalence relations in hash-tables.
Discussion:
With the rejection of all the issues related to EQUAL-STRUCTURE, there is
little or no hope that EQUAL will be "beefed up" to meet the expectations
of so many of the user community on compound structures. If one wants
a hash-table with a :test function that has fewer equivalence classes
(i.e., does more "coalescing"), then there is no alternative now except
to use the function EQUALP.
∂07-Oct-88 1514 LOGMTC-mailer Talk on Non-standard proof normalization by Shigeki Goto
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Oct 88 15:14:08 PDT
Received: from localhost by russell.Stanford.EDU (4.0/4.7); Fri, 7 Oct 88 15:14:50 PDT
To: logic@russell.Stanford.EDU
Subject: Talk on Non-standard proof normalization by Shigeki Goto
Date: Fri, 07 Oct 88 15:14:38 PDT
From: peters@russell.Stanford.EDU
I'm trying to schedule a talk at CSLI by Dr. Shigeki Goto of NTT about
Non-Standard Proof Normalization for Monday afternoon, October 31.
Will anyone have a conflict if the talk is arranged for 3:15? Thanks
for letting me know if you are aware of a problem.
Stanley
∂07-Oct-88 1616 @Score.Stanford.EDU:chandler@polya.Stanford.EDU NSF Publication
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Oct 88 16:15:58 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 7 Oct 88 16:11:52-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA06435; Fri, 7 Oct 88 16:13:03 PDT
Date: Fri, 7 Oct 1988 16:12:39 PDT
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score
Subject: NSF Publication
Message-Id: <CMM.0.87.592269159.chandler@polya.stanford.edu>
NSF Program Announcement and Guidelines, Undergrad Science, Engineering and
Math Education, Instrumentation and Laboratory Improvement - Closing date:
11/21/88 - This publication is available for your perusal in my office.
∂07-Oct-88 1642 X3J13-mailer Issue: LAMBDA-FORM (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 16:42:42 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 16:07:33 PDT
Date: 7 Oct 88 16:07 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: LAMBDA-FORM (Version 3)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-160733-1324@Xerox>
!
Issue: LAMBDA-FORM
References: LAMBDA (p59)
Category: ADDITION
Edit history: 22-Jun-88, Version 1 by Pitman
16-Sep-88, Version 2 by Pitman
02-Oct-88, Version 3 by Pitman
Status: For Internal Discussion
Problem Description:
In Scheme, one writes not #'(LAMBDA ...) but just (LAMBDA ...).
Many Common Lisp programmers have asked for this feature.
It can be written by the user, but since it's a commonly asked
for feature, it would make sense for it to be in the standard.
Also, even though the definition is trivial,
(DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))
it is difficult to offer this as an extension because then "portable
code" tries to define it, it will get a redefinition warning because
it will be clobbering the system's predefined definition.
[An implementation could shadow LAMBDA, but that, too, has associated
problems.]
Proposal (LAMBDA-FORM:NEW-MACRO):
Add a LAMBDA macro, which has equivalent effect to:
(DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))
Rationale:
This is an upward-compatible extension which ``codifies current
practice'' in that it makes a commonly defined macro available
as a standard part of the language.
Test Case:
#1: (DEFUN ADDER (N) (LAMBDA (X) (+ X N)))
(FUNCALL (ADDER 5) 3) => 8
#2: (MAPCAR (LAMBDA (X) (+ X 3)) '(1 2 3)) => (4 5 6)
#3: (MACROEXPAND '(LAMBDA (X) (+ X Y)))
=> (FUNCTION (LAMBDA (X) (+ X Y)))
Current Practice:
Symbolics Genera implements NEW-MACRO.
Symbolics Cloe does not offer a LAMBDA macro because users who defined
their own in portable code complained that they were getting redefinition
warnings that CLtL had led them to believe shouldn't happen. [Ironically,
the redefinition warnings always came when they tried to define LAMBDA
in the way it was already defined!]
Cost to Implementors:
The cost is trivial. A portable definition is shown in the
problem description above.
Cost to Users:
None. This change is basically upward compatible.
Cost of Non-Adoption:
There are no really major consequences of non-adoption.
Benefits:
It's been suggested that some people write '(LAMBDA ...) rather than
#'(LAMBDA ...) because it's less ugly, and then run into confusion
later. If they could just write (LAMBDA ...), some that use overly
superficial reasons for the choice of one notation over another might
accidentally select the primitive they should probably really be using.
Aesthetics:
Some people believe that this makes two different ways to get
essentially the same functionality, and so it clutters the language.
On the other hand, there is at least one precedent for having two
operations that do the identical thing -- NOT and NULL. Both have
been retained because they express different intents. In this case,
the intent of #'xxx might be to ``access'' a function by name (the
name of an anoymous function being its lambda expression), and the
intent of (LAMBDA ...) is to ``create'' a function. This distinction
is subtle but may be expressionally interesting to some programmers
in some situations.
Notationally, some people believe strongly that (LAMBDA ...) looks
a lot better than #'(LAMBDA ...). Certainly it takes up fewer
characters, and (LAMBDA ...) is a notable offender in code needing
to be split onto multiple lines, so every little bit probably helps.
Discussion:
Numerous people have suggested this from time to time in the past,
but it's often been amidst a bunch of other more controversial issues.
Pitman wrote up this proposal and supports LAMBDA-FORM:NEW-MACRO.
Technically, CLtL does already permit implementations to predefine a
LAMBDA macro, but most argue that this leeway was accidental. CLtL
says that "all" functions, etc in CLtL must be in the LISP package,
but it does not say "all and only". This oversight leaves enough room
for implementors to add all manner of extra junk in the LISP package.
A separate cleanup item addresses this issue.
An earlier revision of this proposal considered the alternative of
making this a new special form, but most people seemed to prefer the
simpler alternative of just making it a macro for now.
∂07-Oct-88 1643 X3J13-mailer Issue: NTH-VALUE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 16:43:04 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 16:38:01 PDT
Date: 7 Oct 88 16:38 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: NTH-VALUE (Version 3)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-163801-1388@Xerox>
Issue: NTH-VALUE
References: Multiple values, pp. 133-139
Category: ADDITION
Edit history: 16-Aug-88, Version 1 by Pierson
01-Oct-88, Version 2 by Pitman (minor edits)
5-Oct-88, Version 3 by Masinter
(add Current Practice as per Gray)
Problem description:
The set of operations on multiple values in Common Lisp is incomplete:
The only ways to retrieve just one of several return values (other than
the first) are:
- Bind several variables and then ignore all but one.
eg, (MULTIPLE-VALUE-BIND (X Y Z) <exp> (DECLARE (IGNORE X Y)) Z)
This is somewhat cumbersome to write and not perspicuous.
- Get a list of all return values and select from that.
eg, (THIRD (MULTIPLE-VALUE-LIST <exp>))
This is somewhat cumbersome, not perspicuous, and creates
needless garbage.
Proposal (NTH-VALUE:ADD):
Add a new macro NTH-VALUE, described as
NTH-VALUE n form [Macro]
Evaluates the FORM and returns the Nth value returned by the form as
a single value. N is 0-based, i.e. the first returned value is
value 0 (for consistency with NTH and NTHCDR). Both N and FORM are
evaluated, in left-to-right order.
Test Cases/Examples:
With this proposal MOD could be defined as:
(DEFUN MOD (NUMBER DIVISOR)
(NTH-VALUE 1 (FLOOR NUMBER DIVISOR)))
The same code would currently be:
(DEFUN MOD (NUMBER DIVISOR)
(MULTIPLE-VALUE-BIND (DIVIDEND REMAINDER)
(FLOOR NUMBER DIVISOR)
(DECLARE (IGNORE DIVIDEND))
REMAINDER))
Rationale:
This corrects the stated problem.
Current practice:
The TI Explorer and LMI Lambda have this feature.
Cost to Implementors:
Writing the macro version is fairly straightforward.
Some will choose to implement compiler hooks so that code written with
NTH-VALUE will be as efficient as possible. This may involve some
additional work, but presumably nothing major.
Cost to Users:
This is an upward-compatible change.
Cost of non-Adoption:
The occassional code where this comes up may be one or more of
clumsier to write, more difficult to read, or less efficient.
(The feature is rarely used in implementations that have it.)
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
While it does add another function to the language it removes
some need for the hairier multiple-value forms.
Discussion:
Pitman proposed this in the very late pre-CLtL days. It was
rejected then because it was too late in the cycle.
There was not strong sentiment for including this feature
in Common Lisp, but no active opposition.
∂07-Oct-88 1643 misha@polya.Stanford.EDU Next AFLB.
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Oct 88 16:43:22 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA08466; Fri, 7 Oct 88 16:38:10 PDT
Date: Fri, 7 Oct 88 16:38:10 PDT
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8810072338.AA08466@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: Next AFLB.
The next AFLB meeting is (as usual) on Thursday October 13, at 12:30
in room 352.
----------------------------------------------------------------------------
THE PARALLEL COMPLEXITY OF PERFECT MATCHING
AND ALGEBRAIC INTERPOLATION PROBLEMS
MAREK KARPINSKI
UNIVERSITY OF BONN
AND
ICSI BERKELEY
ABSTRACT.
We construct a fast parallel algorithm for enumerating all the perfect
matchings in bipartite graphs with polynomially bounded permanents. Some
implications towards the general maximum matching and counting problems
are formulated as well as some surprising applications towards efficient
deterministic interpolation schemes for polynomials over arbitrary fields.
These results imply in particular the existence of efficient deterministic
sparse conversion algorithms working over arbitrary fields, and the first deter
ministic polynomial time (and boolean NC) algorithm for the separation of
numerator and denominator of general rational functions. As another appli-
cation we display a deterministic polynomial time (boolean NC) RSE-conversion
algorithm for the sparse boolean circuits. The last result implies that
the SPARSE SAT Problem is in P, and in deterministic NC.
--------------------------------------------------------------------------------
The week after next the aflb will probably be on Tuesday October 18, at 12:30
in room 252 (Note unusual time and place).
The talk will be by Milena Mihail on the magnification properties of
the matching polytopes (related to the Jerrum & Sinclair results).
The upcoming FOCS paper is by Dagum, Luby, Mihail and Vazirani.
misha
∂07-Oct-88 1721 @Score.Stanford.EDU:tom@polya.Stanford.EDU MJH cooling problems
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Oct 88 17:20:59 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 7 Oct 88 17:16:25-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA12603; Fri, 7 Oct 88 17:17:39 PDT
Date: Fri, 7 Oct 88 17:17:39 PDT
From: Tom Dienstbier <tom@polya.Stanford.EDU>
Message-Id: <8810080017.AA12603@polya.Stanford.EDU>
To: csd@score, faculty@score, staff@score
Subject: MJH cooling problems
As some of you probably can tell the building is much warmer then usual.
This is do to a cut-back in chilled water. We have diverted all of the
chilled water that we get to the main machine room. The effect is that
most of the other parts of the building will run much warmer.
tom
∂07-Oct-88 2151 X3J13-mailer Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 21:50:40 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 20:55:12 PDT
Date: 7 Oct 88 20:55 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-205512-1714@Xerox>
!
Issue: RANGE-OF-START-AND-END-PARAMETERS
References: COUNT (p257), COUNT-IF (p257), COUNT-IF-NOT (p257),
DELETE (p257), DELETE-DUPLICATES (p254), DELETE-IF (p254),
DELETE-IF-NOT (p254), FILL (p252), FIND (p257), FIND-IF (p257),
FIND-IF-NOT (p257), MAKE-STRING-INPUT-STREAM (p330),
MISMATCH (p257), NSTRING-CAPITALIZE (p304),
NSTRING-DOWNCASE (p304), NSTRING-UPCASE (p304), SUBSTITUTE (p255),
NSUBSTITUTE-IF (p256), NSUBSTITUTE-IF-NOT (p256),
PARSE-INTEGER (p381), PARSE-NAMESTRING (p414), POSITION (p257),
POSITION-IF (p257), POSITION-IF-NOT (p257),
READ-FROM-STRING (p381), REDUCE (p251), REMOVE (p253),
REMOVE-DUPLICATES (p254), REMOVE-IF (p253), REMOVE-IF-NOT (p253),
REPLACE (p252), SEARCH (p258), STRING-CAPITALIZE (p303),
STRING-EQUAL (p301), STRING-DOWNCASE (p303), STRING-GREATERP (p302),
STRING-LESSP (p302), STRING-NOT-EQUAL (p302),
STRING-NOT-GREATERP (p302), STRING-NOT-LESSP (p302),
STRING-UPCASE (p303), STRING/= (p301), STRING< (p301),
STRING<= (p301), STRING= (p300), STRING> (p301), STRING>= (p301),
SUBSEQ (p248), SUBSTITUTE (p255), SUBSTITUTE-IF (p255),
SUBSTITUTE-IF-NOT (p255), WRITE-LINE (p384), WRITE-STRING (p384)
Category: CLARIFICATION
Edit history: 14-Sep-88, Version 1 by Pitman
Problem Description:
CLtL is not always clear about the possible values which the START and END
parameters of built-in Common Lisp can take.
Proposal (RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL):
Clarify that for functions permitting a parameter named START, START1,
or START2 which delimits the beginning point in a sequence to be
considered for some operation, that paremeter must be a non-negative
integer. If the argument is optional or key (as is the case for all
functions referenced above except SUBSEQ), the value will default to
0 if not supplied. It is not permissible to pass NIL as this argument.
Clarify that for functions permitting a parameter named END, END1,
or END2 which delimits the end point in a sequence to be considered
for some operation, that paremeter must be a non-negative integer
indicating a termination point or NIL indicating the last element
in the sequence. If the argument is optional or key (as is the case
for all functions referenced above), the value will default to NIL
if not supplied. Supplying NIL is, therefore, equivalent to not
supplying this argument.
Test Case:
(SEARCH "F" "FOO" :START1 NIL) is an error.
(SEARCH "F" "FOO" :START2 0) is permissible and is equivalent to
(SEARCH "F" "FOO")
(SEARCH "F" "FOO" :END2 NIL) is permissible and is equivalent to
(SEARCH "F" "FOO")
Rationale:
To keep data flow between programs from becoming excessively complicated,
it's a good idea to specify what the default values are so that they can
be passed explicitly rather than requiring an alternate calling sequence
for all possible cases where the value might need to default.
Current Practice:
Symbolics Genera implements the proposed behavior.
Cost to Implementors:
Hopefully most implementations already do this. Those that do not will
probably have to make quite a number of small changes to both the code
for these functions and to any associated compiler optimizers.
Cost to Users:
This change is upward compatible with existing user code. Any program
which did not conform to this proposal was already not portable.
Cost of Non-Adoption:
Subtle gratuitous differences in the handling of these arguments would
continue to be a possibility and a barrier to portability.
Benefits:
The language would be more regular and well-defined.
Aesthetics:
If it makes things clearer, it's an improvement.
Discussion:
Pitman supports RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL.
∂07-Oct-88 2151 X3J13-mailer Issue: SETF-FUNCTION-VS-MACRO (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 21:51:00 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 OCT 88 21:26:56 PDT
Date: 7 Oct 88 21:26 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: SETF-FUNCTION-VS-MACRO (version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
line-fold: NO
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <881007-212656-1734@Xerox>
This issue was distributed at the November 1987 meeting.
It was tabled to allow for discussion of function specs.
The only mail comments, which have not been incorporated,
have been:
Instead of generalizing SYMBOL-FUNCTION, add FDEFINITION and leave
SYMBOL-FUNCTION alone.
Do not modify TRACE and UNTRACE. Leave them implementation-dependent.
!
Issue: SETF-FUNCTION-VS-MACRO
References: SETF rules for what -place- can be (pp.94-7)
COMPILE function (p.438)
DEFUN macro (p.57)
DISASSEMBLE function (p.439)
DOCUMENTATION function (p.440)
FBOUNDP function (p.90)
FLET special form (p.113)
FMAKUNBOUND function (p.92)
FTYPE declaration (p.158)
FUNCTION special form (p.87)
FUNCTION declaration (p.159)
INLINE declaration (p.159)
NOTINLINE declaration (p.159)
LABELS special form (p.113)
SYMBOL-FUNCTION and setf of symbol-function (p.90)
TRACE macro (p.440)
UNTRACE macro (p.440)
Category: ADDITION
Edit history: Version 1, 13-Oct-87 Moon
(based on discussion among the CLOS working group)
Version 2, 26-Oct-87 Masinter, minor mods
Version 3, 4-Nov-87 Moon, small clarifications at KMP's urging
PROBLEM DESCRIPTION:
The Common Lisp Object System needs a well-defined way to relate the
name and arguments of a setting function to those of a reading function,
because both functions can be generic and can have user-defined methods.
We tried to hide the name and arguments of the setting function with
macrology, but the complexity got out of hand. It seems better to make
this information explicit; the version of the CLOS specification that
assumes the adoption of proposal SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
is much simpler in the relevant areas.
PROPOSAL (SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS):
Add to Common Lisp the concept of "setf functions". Right now, Common
Lisp only has "setf macros", which are defined by define-setf-method and
both forms of defsetf. Terminology:
- a "setf macro" is something that produces code (or other
specifications, as in define-setf-method) which, when evaluated,
will perform the effect of an invocation of setf.
- a "setf function" is something that is called to perform
directly the effect of an invocation of setf.
The form (setf (-name- ...) ...), when -name- is defined as a function
(rather than a macro) and no setf macro has been defined for -name-,
expands into a call to a setf function. The name of this setf function
is a list (setf -name-), where -name- is a symbol. The body of this
function is surrounded by an implicit block named -name-.
The functions, macros, special forms, and declarations defined in CLtL
and listed in the References section above need to be enhanced to accept
such lists in addition to symbols as function names, so that setf
functions can be defined and manipulated.
A setf function receives the new value to be stored as its first
argument. Thus, #'(setf foo) should have one more required parameter
than #'foo, the first required parameter is the new value to be stored,
and the remaining parameters should be the same as #'foo's parameters.
A setf function must return its first argument, since setf is defined
to return the new value.
A definition of a setf function can be lexically local, like a
definition of a reading function. The following rules specify the
behavior of SETF; note that these rules are ordered and the first rule
to apply supersedes any later rules. These rules are a consistent
extension of the current behavior of Common Lisp and the Cleanup
committee's resolution of issue GET-SETF-METHOD-ENVIRONMENT. Only
rule 4 is new with this proposal.
Rules for the macroexpansion of (setf (foo x) y):
(1) If the function-name foo refers to the global function definition,
rather than a locally defined function or macro, and if there is a
setf macro defined for foo, use the setf macro to compute the expansion.
(2) If the function-name foo is defined as a macro in the current scope,
use macroexpand-1 to expand (foo x) and try again.
(3) If the function-name foo is defined as a special form in the current
scope, signal an error.
(4) Expand into the equivalent of
(let ((#:temp-1 x) ;force correct order of evaluation
(#:temp-2 y))
(funcall #'(setf foo) #:temp-2 #:temp-1))
Note that rule 4 is independent of the scope of the function name
(setf foo). It does not matter if that scope is different from the
scope of the function name foo. This allows some nonsensical programs
to be written, but does not seem harmful enough to justify making more
complicated rules to compare the scopes of the two function definitions.
The above rules are actually implemented by GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE, rather than by the SETF macro itself.
Thus GET-SETF-METHOD generates the appropriate five values for a form
that is not a macro-invocation and does not have a defined setf macro.
Normally one does not define both a setf function and a setf macro
for the same reading function.
Normally one defines a local reading function and a local setf function
together in a single FLET or LABELS.
In the absence of any setf macro definition, SETF of a function expands
into a call to the setf function. This means that the setf function
only needs to be defined at run time, not compile time.
What CLtL says about (documentation foo 'setf) will not change.
Specifically, the setf documentation type applies just to defsetf (and
define-setf-method, that's an omission in CLtL). The documentation for
a setf function, as for any function, is retrieved by
(documentation '(setf foo) 'function).
Examples:
;If SETF of SUBSEQ was not already built into Common Lisp,
;it could have been defined like this
(defun (setf subseq) (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value j))))
;Another example, showing a locally defined setf function
(defun frobulate (mumble)
(let ((table (mumble-table mumble)))
(flet ((foo (x)
(gethash x table))
((setf foo) (new x)
(setf (gethash x table) new)))
..
(foo a)
..
(setf (foo a) b))))
;get-setf-method could implement setf functions by calling
;this function when rules 1-3 do not apply
(defun get-setf-method-for-setf-function (form)
(let ((new-value (gensym))
(temp-vars (do ((a (cdr form) (cdr a))
(v nil (cons (gensym) v)))
((null a) v))))
(values temp-vars (cdr form) (list new-value)
`(funcall #'(setf ,(car form))
,new-value ,@temp-vars)
`(,(car form) ,@temp-vars))))
RATIONALE:
By making the names and arguments of setting functions explicit, CLOS is
considerably simplified. In addition, this can supersede any proposals
to introduce a lexically local form of defsetf; lexically local setf
functions serve the same needs.
Current code that resembles
(defsetf foo |setf FOO|)
(defun foo (x) ..)
(defun |setf FOO| (x new) ..)
or
(defsetf foo internal-foo-setter)
(defun foo (x) ..)
(defun internal-foo-setter (x new) ..)
can be, but is not required to be, replaced with the following code
(defun foo (x) ..)
(defun (setf foo) (new x) ..)
An advantage of this is that several disparate styles of using
DEFSETF can be replaced with a single common style of using
setf functions, making programs more standardized and readable.
CURRENT PRACTICE:
A few Common Lisp implementations already have a similar feature,
in that they allow setting functions named (SETF reader). We don't
know of any implementation that has precisely the proposed feature.
ADOPTION COST:
The main cost is generalization of a few functions to accept lists
beginning with SETF where they now accept only symbols. Implementations
must add a data structure to store the function definition of a setf
function, however, this can trivially be done with property lists or
generated symbols.
The cost of making the SETF macro expand into a call to a setf function,
when it does not find a setf macro or a regular macro to expand, is
negligible.
This will be an incompatible change for Symbolics, since it already has
setf functions but they do not take the same arguments as proposed here.
However, the change is considered worthwhile.
COST OF NON-ADOPTION:
Non-adoption of this proposal would be a significant roadblock to the
Common Lisp Object System. Some major rethinking of CLOS would be
required.
BENEFITS:
Allow CLOS to be defined without out-of-hand complexity.
Improve usability of SETF.
CONVERSION COST:
None, this is an upward-compatible change.
As with any language extension, some program-understanding programs may
need to be enhanced. A particular issue here is programs that assume
that all function names are symbols. They may use GET to access
properties of a function name or use EQ or EQL (perhaps via MEMBER or
ASSOC) to compare function names for equality. Such programs will need
improvement before they can understand programs that use the new
feature, but otherwise they will still work.
ESTHETICS:
SETF would be more esthetic, but less powerful, if it had only the
proposed setf functions and did not have setf macros. Such a major
incompatible change is of course out of the question; however, if setf
functions are stressed over setf macros, SETF will be much easier to
teach.
DISCUSSION:
Note that in Common Lisp, setf macro expansion is an operation on
function names, not on functions. It differs from some dialects of
Scheme, such as T, in this respect. This proposal does not attempt to
change that.
There was some concern about introducing the notion that the name of the
setf-function associated with FOO should be a list, (SETF FOO). This is
a considerable extension to the idea of a "function name", at least for
standard Common Lisp implementations that do not implement Lisp machine
style function-specs.
However, the CLOS unsuccessfully tried a number of alternatives.
Fundamentally the problem is that there has to be a name that the user
uses to define the thing and to talk about it. Trying to hide the name
just means you use a more obscure name, like an alternate syntax for
DEFUN or DEFUN-SETF. Another reason for making the name explicit is to
allow one to use FLET for the setf function -- something which would be
difficult if there is not a name-like entity that can be bound.
This proposal is not incompatible with other extensions to function
specifications present in some implementations.
The following related features were considered but are specifically
not being proposed at this time, since they are unnecessary for CLOS
and appear not to improve the simplicity and esthetics of the language:
a) Lexically local setf macros, that is, a cross between DEFSETF and
MACROLET. This does not appear to be logically necessary. Would all
three ways of defining lexically global setf macros need local
counterparts?
b) Define the meaning of defmacro or macrolet of (setf foo)?
This would be a fourth way to define a setf macro.
c) Enhance the definition of global setf macros, for example to
say that (MACRO-FUNCTION '(SETF FOO)) returns an expander function
that takes two arguments and returns five values.
d) Introduce a new name for SYMBOL-FUNCTION, since it accepts
non-symbols now.
e) Should one allow these extended function names in the car-position
of an expression to be evaluated? The extra complexity didn't seem
justified, instead, an explicit FUNCALL is required.
∂07-Oct-88 2152 X3J13-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 21:51:58 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 21:50:05 PDT
Date: 7 Oct 88 21:50 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-215005-1749@Xerox>
!
Issue: STANDARD-INPUT-INITIAL-BINDING
References: Standard streams (pp. 327-329)
Category: CHANGE
Edit history: Version 1 by Pierson and Haflich 1/19/87
Version 2 by Pierson 2/29/88
Version 3 by Pierson 5/23/88, per comments by Moon
Version 4 by Pierson 5/26/88, clean up
Version 5 by Pierson 6/28/88, simple design per Masinter
Version 6 by Pierson 7/ 5/88, clean up and split issue
Version 7 by Pierson 7/ 8/88, clean up per Pitman
Version 8 by Pierson 7/ 8/88, yet more clean up
Status: Ready for Release?
Problem description:
CLtL requires that *STANDARD-INPUT*, *STANDARD-OUTPUT*,
*ERROR-OUTPUT*, *TRACE-OUTPUT*, *QUERY-IO*, and *DEBUG-IO* are
initially bound to synonym streams to *TERMINAL-IO*. This requirement
hampers the integration of Common Lisp with many existing and
potential operating environments.
For example, a Unix implementation is currently unable to legally
support Unix standard error output even though Common Lisp defines
*ERROR-OUTPUT* because *ERROR-OUTPUT* is required to start out bound
to the same stream as *STANDARD-OUTPUT*. A workstation environnment
which provides stream access to windows as an extension is currently
forbidden to make trace output appear in a separate window by default
because *TRACE-OUTPUT* is required to start out bound to the same
stream as *STANDARD-OUTPUT*.
Proposal (STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS):
A Common Lisp implementation is required to provide the following
initial streams. Each initial stream has a specific purpose as
defined in CLtL. This proposal redefines the initial bindings of
the streams and leaves the rest of the CLtL description unchanged.
*TERMINAL-IO*
*STANDARD-INPUT*
*STANDARD-OUTPUT*
*ERROR-OUTPUT*
*TRACE-OUTPUT*
*QUERY-IO*
*DEBUG-IO*
The initial bindings of these variables are undefined except
that:
1. They are all initially bound to open streams.
2. The streams must support input and/or output as
indicated by the variable name.
3. None of the standard streams (including *TERMINAL-IO*)
may be directed by synonym streams to another of these
stream variables (except *TERMINAL-IO*), whether
directly or by indirection via some composite stream
such as a two way stream with one of the arms being a
synonym stream.
4. Any or all of these streams may be synonyms for the
common implementation dependent stream. For example,
in an interactive Common Lisp invocation running on a
character terminal, all of the streams mentioned here
might be synonym streams (or two-way streams to synonym
streams) to a pair of hidden terminal input/output
streams maintained by the implementation.
The intent of the above rules is to ensure that it is always
safe to bind any of the above variables to another of the
above variables without unduly restricting implementation
flexibility.
Test Cases/Examples:
(PROGN
(PRINT "Output" *STANDARD-OUTPUT*)
(PRINT "Error" *ERROR-OUTPUT*))
In current Common Lisp will write:
------
Output
Error
------
With proposal *might* write:
------
Output
------
and "Error" appears somewhere else.
(LET ((*STANDARD-OUTPUT* *DEBUG-IO*))
...)
In current Common Lisp:
Might cause a circular stream reference if *DEBUG-IO* was
bound to a two-way stream made up of synonym streams to
*STANDARD-INPUT* and *STANDARD-OUTPUT*.
With this proposal:
Would be guaranteed not to cause a circular stream reference
unless the initial value of *DEBUG-IO* had been changed to a value
that did not conform the restrictions in this proposal. While no
Common Lisp implementation should do this, a user program might.
(LET ((*STANDARD-INPUT* *TERMINAL-IO*)
(*STANDARD-OUTPUT* *TERMINAL-IO*))
...)
In current Common Lisp:
Might cause a circular stream reference because *TERMINAL-IO* was
bound to a two-way stream made up of synonym streams to
*STANDARD-INPUT* and *STANDARD-OUTPUT*.
With this proposal:
Would be guaranteed not to cause a circular stream reference.
Rationale:
This proposal attempts to provide a balance between over-specifying
behavior to the point that Lisp programs can't behave like other
programs in conventional operating systems and providing enough
specification that Common Lisp programs can perform portable input and
output.
Current practice:
Lucid binds *TERMINAL-IO* to a special internal stream type. Franz
binds *TERMINAL-IO* to a special internal stream type for terminal
streams which reads from Unix standard input and writes to Unix
standard output. KCL binds *TERMINAL-IO* to a standard two-way-stream
with input from Unix standard input and output to Unix standard
output. Symbolics Genera binds *TERMINAL-IO* as appropriate for each
process, usually to a window for interactive applications or to a
stream which will conjure an interaction window on demand for
background tasks.
Cost to Implementors:
All implementations will have to change to some degree but the changes
will probably be simple and localized. All known implementations
already support the underlying streams required to implement this
proposal.
Cost to Users:
User code which depends on the strict binding hierarchy in CLtL may
have to change.
Cost of non-Adoption:
It will continue to be difficult or impossible to integrate portable
Common Lisp progams in conventional operating system environments.
Many implementations will have to continue to choose between
conforming to the standard and providing a superior user environment.
Benefits:
Implementations will be more able to match their IO behavior to their
environment and their user's expectations.
Aesthetics:
Improved because this area becomes better defined.
Discussion:
Moon says that *TERMINAL-IO* (and, by extension, *QUERY-IO*, and
*DEBUG-IO*) should fail to work in a non-interactive environment where
nothing like a terminal exists. This proposal fails to address this.
Masinter notes that:
``In many multi-processing multi-window environments,
the "initial binding" for *STANDARD-INPUT*, *QUERY-INPUT*
differs for each process.''
Pierson and Pitman support STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS.
----- End Forwarded Messages -----
∂07-Oct-88 2151 X3J13-mailer Issue: RETURN-VALUES-UNSPECIFIED (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 21:50:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 OCT 88 21:16:06 PDT
Date: 7 Oct 88 21:16 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: RETURN-VALUES-UNSPECIFIED (Version 4)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-211606-1727@Xerox>
!
Issue: RETURN-VALUES-UNSPECIFIED
References: CLOSE (p 332), IN-PACKAGE (p 183), RENAME-PACKAGE (p 184),
TRACE (p 440), UNTRACE (p 440), INSPECT (p 442),
SET-SYNTAX-FROM-CHAR (p 361),
LOCALLY (p 156), PROVIDE (p 188), REQUIRE (P 188)
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
19-Sept-88, Version 2 by Chapman
6-Oct-88, Version 3 by Masinter
7-Oct-88, Version 4 by Masinter
Problem Description:
The descriptions of CLOSE, IN-PACKAGE, RENAME-PACKAGE, TRACE, UNTRACE,
INSPECT, SET-SYNTAX-FROM-CHAR, LOCALLY, PROVIDE, and REQUIRE
are not clear about the values returned from those constructs.
Proposal (RETURN-VALUES-UNSPECIFIED:SPECIFY)
Clarify that the return values for the listed constructs are as follows:
CLOSE -- the stream argument.
IN-PACKAGE -- the new package, i.e. the value of *PACKAGE* after the
execution of IN-PACKAGE.
RENAME-PACKAGE -- the renamed package.
TRACE (when called with arguments) -- implementation-dependent.
UNTRACE -- implementation-dependent.
INSPECT -- implementation-dependent.
SET-SYNTAX-FROM-CHAR -- T
LOCALLY -- the return values of the last form of its body, i.e. the body is
surrounded by an implicit PROGN.
PROVIDE -- implementation-dependent.
REQUIRE -- implementation-dependent.
Rationale:
This clarification allows users to know when they can and can not
count on the values returned from these constructs.
Current Practice:
Varies. For example, in Envos Medley, CLOSE returns T, and
set-syntax-from-char returns the "syntax class" of the new character.
Cost to Implementors:
Small.
Benefits:
This clarification will assist users in writing portable code.
Cost to users:
Small; it seems unlikely that there is much code that currently
depends on the return values of these functions; such code isn't
portable.
Aesthetics:
Specified is better than not, when it makes sense.
Discussion:
PROVIDE and REQUIRE are not likely to appear except in the "top level" of
files, and so their return value is possibly moot. There is also some
sentiment for leaving unspecified the values of the debugging/environment
features such as TRACE and UNTRACE, to allow for experimentation and
growth.
∂07-Oct-88 2150 X3J13-mailer Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 21:50:30 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 19:35:45 PDT
Date: 7 Oct 88 19:35 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
To: X3J13@SAIL.Stanford.EDU
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-193545-1651@Xerox>
Another proposal to extend this to other pathname components
will probably be submitted, but not in time for this meeting.
!
Issue: PATHNAME-TYPE-UNSPECIFIC
References: Pathnames (pp410-413)
Category: CHANGE
Edit history: 27-Jun-88, Version 1 by Pitman
Problem Description:
CLtL (p412) specifies that the type is ``always a string, NIL,
or :WILD.'' This description is too restrictive to be practical.
In file systems which have no first-class notion of a name/type
distinction, it is possible to make files named "foo." and "foo"
which are distinct. One of these (usually the former) can get a
type of "" but it is not clear how to represent the other. If
NIL is used, merging primitives cannot detect that the field is
filled and should not be merged against.
Proposal (PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN):
Permit :UNSPECIFIC as a value of the type field of a pathname for
operating systems in which it makes sense.
When a pathname is converted to a namestring, NIL and :UNSPECIFIC
both cause the component not to appear in the string.
When merging, however, a NIL value for a component will be replaced
with the default for that component, while :UNSPECIFIC will be left
alone.
Test Case:
For file systems where :UNSPECIFIC makes sense...
(PATHNAME-TYPE (MAKE-PATHNAME :TYPE :UNSPECIFIC)) => :UNSPECIFIC
(PATHNAME-TYPE (MERGE-PATHNAMES (MAKE-PATHNAME :TYPE :UNSPECIFIC)
(MAKE-PATHNAME :TYPE "FOO")))
Rationale:
This is, by necessity, current practice in some implementations
already.
Current Practice:
Symbolics Genera uses a file type of :UNSPECIFIC on Unix and
ITS file systems, for example.
Cost to Implementors:
None. No change to any implementation is forced.
Some implementations which use a non-standard token other than :UNSPECIFIC
to implement this functionality might want to switch to use :UNSPECIFIC so
that portable programs could expect it.
Cost to Users:
Some programs which manipulate pathnames should be updated to expect
:UNSPECIFIC in the type fields in some situations.
Any program which doesn't already expect :UNSPECIFIC is already not really
portable, however, given that some implementations have been forced to
go beyond the standard in order to represent all possible pathnames.
Cost of Non-Adoption:
Some implementations would be unable to both represent all possible pathnames
in a rational way and at the same time to conform to the standard.
Benefits:
Some programs involving pathnames would be more portable.
Aesthetics:
Sweeping a hairy situation under the rug doesn't make it go away.
This change makes things appear less simple, but since in reality
they were less simple, it is effectively a simplification of the
correspondence between the CL model and reality.
Discussion:
Pitman supports PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN.
This feature existed in the Colander draft edition of CLtL, but was
removed for the Laser edition. The following text is excerpted from
the Colander edition, p259:
``??? Query: Is :unspecific really needed over and above nil?
``A component of a pathname can also be the keyword
:UNSPECIFIC. This means that the component has been explicitly
determined not to be there, as opposed to be missing. One way
this can occur is with generic pathnames, which refer not to
a file but to a whole family of files. The version, and usually
the type, of a generic pathname are :unspecific. Another way
:unspecific is used to represent components that are not simply
supported by a file system. When a pathname is converted to a
namestring, nil and :unspecific both cause the component not to
appear in the string. When merging, however, a nil value for
a component will be replaced with the default for that
component, while :unspecific will be left alone.''
∂07-Oct-88 2206 X3J13-mailer STEP-ENVIRONMENT, version 3
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 22:06:27 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 22:03:43 PDT
Date: 7 Oct 88 22:03 PDT
From: masinter.pa@Xerox.COM
Subject: STEP-ENVIRONMENT, version 3
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-220344-1757@Xerox>
!
Issue: STEP-ENVIRONMENT
References: STEP (CLtL p.441)
TIME (CLtL p.441)
Category: CLARIFICATION/CHANGE
Edit history: Version 1, 12-Mar-88, Moon
Version 2, 10-Jun-88, Masinter (add discussion)
Version 3, 20-Jun-88, Loosemore (not a special form)
Problem description:
CLtL does not specify in what lexical environment the form given to STEP
is evaluated. Some people think it's supposed to be evaluated in the
null environment, others think it is supposed to be evaluated in the
current environment, the one in which the STEP form was evaluated.
The same considerations apply to TIME.
Proposal (STEP-ENVIRONMENT:CURRENT):
1. Clarify that STEP and TIME evaluate the form in the current environment.
2. Clarify that calls to both STEP and TIME may be compiled, but that
in the case of STEP, it is acceptable for an implementation to
interactively step through only those parts of the evaluation that are
interpreted.
Test Cases/Examples:
;Assuming X is not a special variable
(setq x 1)
(let ((x 2))
(step (print x)))
This should print and return 2, not 1, when interpreted.
Rationale:
1. It is more useful for the lexical environment to pass transparently
through STEP and TIME than to reset to the null environment.
2. Although STEP is primarily a debugging tool, there is no reason to
prevent it from being compiled correctly.
Current practice:
Vax Lisp behaves as proposed. Symbolics Common Lisp treats STEP as a special
form and does not allow it to be compiled.
Cost to Implementors:
Minimal.
Cost to Users:
None.
Cost of non-adoption:
These debugging tools will continue to have vague specifications.
Benefits:
Slightly more preicse specification of Common Lisp.
Esthetics:
Slightly improved.
Discussion:
There was some discussion of separating this out into two separate
proposals, but it didn't seem useful.
Eric Benson contributed the definition of TIME in Lucid Common Lisp:
(defmacro time (form)
`(time-internal #'(lambda () ,form)))
The function TIME-INTERNAL looks something like:
(defun time-internal (thunk)
(let ((before-time (get-time-state)))
(unwind-protect
(funcall thunk)
(print-time-information before-time (get-time-state)))))
The definition of STEP is similar. This is just to show that it is
easy to get the right lexical environment even though TIME and STEP
are macros.
VaxLisp expands STEP into something like:
(defmacro step (form)
`(let ((*eval-hook* #'step-command-loop))
,form))
∂07-Oct-88 2215 X3J13-mailer Issue: STREAM-ACCESS (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 22:15:36 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 22:11:28 PDT
Date: 7 Oct 88 22:11 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: STREAM-ACCESS (version 1)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-221128-1779@Xerox>
This issue prompted the following comment, which has not been
incorporated:
"The editorial committee should see to it that it's clear that these
types have to do with `structure' rather than `intent' of the resulting
streams. For example, if you broadcast to two string streams, you have a
stream of type BROADCAST-STREAM, not a stream of type STRING-STREAM, etc."
!
Issue: STREAM-ACCESS
References: streams (Chapter 21 of CLtL)
Category: ADDITION
Edit History: 17-Jun-88, version 1 by Walter van Roggen
Problem Description:
There are many components of streams which are specified upon creation
but are not accessible afterwards. Furthermore there is no way in
Common Lisp to determine the type of a stream to see if it has particular
components, or even if it is OPEN.
Proposal: (STREAM-ACCESS:PROVIDE)
Add the following types and functions to the language:
Stream Data Types and Predicates:
BROADCAST-STREAM [Type]
BROADCAST-STREAM-P object [Function]
The predicate is true if the object is of type BROADCAST-STREAM
and is false otherwise. MAKE-BROADCAST-STREAM returns a stream
of type BROADCAST-STREAM.
CONCATENATED-STREAM [Type]
CONCATENATED-STREAM-P object [Function]
The predicate is true if the object is of type CONCATENATED-STREAM
and is false otherwise. MAKE-CONCATENATED-STREAM returns a stream
of type CONCATENATED-STREAM.
ECHO-STREAM [Type]
ECHO-STREAM-P object [Function]
The predicate is true if the object is of type ECHO-STREAM
and is false otherwise. MAKE-ECHO-STREAM returns a stream
of type ECHO-STREAM.
FILE-STREAM [Type]
FILE-STREAM-P object [Function]
The predicate is true if the object is of type FILE-STREAM
and is false otherwise. OPEN returns a stream
of type FILE-STREAM.
STRING-STREAM [Type]
STRING-STREAM-P object [Function]
The predicate is true if the object is of type STRING-STREAM
and is false otherwise. MAKE-STRING-INPUT-STREAM and
MAKE-STRING-OUTPUT-STREAM return a stream of type STRING-STREAM.
SYNONYM-STREAM [Type]
SYNONYM-STREAM-P object [Function]
The predicate is true if the object is of type SYNONYM-STREAM
and is false otherwise. MAKE-SYNONYM-STREAM returns a stream
of type SYNONYM-STREAM.
TWO-WAY-STREAM [Type]
TWO-WAY-STREAM-P object [Function]
The predicate is true if the object is of type TWO-WAY-STREAM
and is false otherwise. MAKE-TWO-WAY-STREAM returns a stream
of type TWO-WAY-STREAM.
Stream Informational Functions:
BROADCAST-STREAM-STREAMS broadcast-stream ==> list of streams
This function returns a list of output streams that constitute
all the streams the broadcast stream is broadcasting to. It is
an error if the argument is not of type BROADCAST-STREAM.
CONCATENATED-STREAM-STREAMS concatenated-stream ==> list of streams
This function returns a list of input streams that constitute
the ordered set of streams the concatenated stream still has to
to read from, starting with the current one it is reading from.
The list may be () if no more streams remain to be read.
It is an error if the argument is not of type CONCATENATED-STREAM.
ECHO-STREAM-INPUT-STREAM echo-stream ==> input-stream
ECHO-STREAM-OUTPUT-STREAM echo-stream ==> output-stream
These functions return the corresponding component stream. It is
an error if the argument is not of type ECHO-STREAM.
SYNONYM-STREAM-SYMBOL synonym-stream ==> symbol
This function returns the symbol whose SYMBOL-VALUE the
synonym stream is using. It is
an error if the argument is not of type SYNONYM-STREAM.
TWO-WAY-STREAM-INPUT-STREAM two-way-stream ==> input-stream
TWO-WAY-STREAM-OUTPUT-STREAM two-way-stream ==> output-stream
These functions return the corresponding component stream. It is
an error if the argument is not of type TWO-WAY-STREAM.
Predicate:
OPEN-STREAM-P stream
Returns T if a stream is open, NIL if it is closed. It is an error
if the argument is not a stream.
Current Practice:
VAX LISP implements the proposal.
Cost to Implementors:
Most of these should be trivial to implement, since the information
must be present for nearly all types.
Cost to Users:
None. This is an upward-compatible extension.
Cost of Non-Adoption:
The benefits would not be available in a portable fashion.
Benefits:
Programs would be able to access useful information otherwise hidden.
Discussion:
This issue has come up frequently, particularly dealing with SYNONYM-STREAMs.
∂07-Oct-88 2317 X3J13-mailer Issue: SUBTYPEP-TOO-VAGUE (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 23:16:57 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 23:15:12 PDT
Date: 7 Oct 88 23:15 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: SUBTYPEP-TOO-VAGUE (Version 4)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-231512-1832@Xerox>
!
Issue: SUBTYPEP-TOO-VAGUE
References: CLtL p. 72-73
Category: CLARIFICATION
Edit History: Version 1, 11 Jul 1988 (Sandra Loosemore)
Version 2, 19 Jul 1988 (Sandra Loosemore)
Version 3, 6-Oct-88 (Masinter)
Version 4, 7-Oct-88 (Masinter, per Moon's comments)
Problem Description:
The description of SUBTYPEP allows it to return a second value of NIL
when the relationship between the two types cannot be determined. In
some cases this is a reasonable thing to do because it is impossible
to tell (if the SATISFIES type specifier is involved), and in other
cases the relationships between types are not well-defined (for
example, the VALUES type specifier or the list form of the FUNCTION
type specifier).
Some implementations, however, have apparently interpreted this to
mean that it is permissible for SUBTYPEP to "give up" and return a
second value of NIL in some cases where it actually would be possible
to determine the relationship. This makes it difficult to depend on
subtype relationships in portable code.
Proposal: SUBTYPEP-TOO-VAGUE:CLARIFY
A type specifier "involves" a word like SATISFIES, MEMBER, NOT, etc.
if it either contains it directly or as the result of expansion of a
DEFTYPE defined type specifier.
* Clarify that SUBTYPEP will return a second value of NIL
only when either of the type specifiers involves the SATISFIES, NOT,
AND, OR, MEMBER. SUBTYPEP will not return a second
value of NIL when both arguments involve only the words in Table 4-1, or
names of DEFSTRUCT- or DEFCLASS-defined types, or user-defined deftypes
that expand into only those words and/or names.
* SUBTYPEP should signal an error when handed (for either argument)
a type specifier that involves VALUES or the list form of the FUNCTION
type.
* SUBTYPEP must always return values T T in the case where the two
type specifiers (or their expansions) are EQUAL.
* Clarify that the relationships between types reflected by SUBTYPEP
are those specific to the particular implementation. For example, if
an implementation supports only a single type of floating-point numbers,
in that implementation (SUBTYPEP 'FLOAT 'LONG-FLOAT) would return T T
(since the two types would be identical).
Rationale:
Specifying the behavior of SUBTYPEP makes it more useful. Otherwise,
programs cannot rely on any more than NIL NIL as return values.
It is generally conceded that it is impossible to determine the
relationships between types defined with the SATISFIES specifier.
MEMBER, AND, OR, and NOT are messy to deal with.
Current Practice:
The implementation of SUBTYPEP in (the original) HPCL does not try to
expand type specifiers defined with DEFTYPE and does not recognize
EQUAL type specifiers as being equivalent. Most other implementations
appear to be substantially in conformance with the proposal.
Cost to implementors:
Some implementations will have to rewrite and/or extend parts of SUBTYPEP.
Cost to users:
Its hard to imagine a portable program that depends heavily
on SUBTYPEP. This proposal does not require any implementation
to "handle" fewer cases of SUBTYPEP.
Benefits:
An area of confusion in the language is cleared up. Usages of SUBTYPEP
will be more portable.
Discussion:
The handling of FLOAT and SINGLE-FLOAT appeared to be the
consensus from a discussion on the common-lisp mailing list some
time ago.
It would not be too onerous to require implementations to handle
the cases where one but not the other type specifier involves
OR, AND, NOT or MEMBER, but the specification becomes
cumbersome.
A related issue is clarifying what kinds of type specifiers must be
recognized by functions such as MAKE-SEQUENCE and COERCE. For example,
HPCL complains that (SIMPLE-ARRAY (UNSIGNED-BYTE *) (*)) is not a valid
sequence type when passed to MAKE-SEQUENCE, although SUBTYPEP does
recognize it to be a subtype of SEQUENCE. Should this proposal be
extended to deal with these issues, or is another proposal in order?
The rules for comparing the various type specifiers (such as ARRAY)
need to be spelled out in detail.
∂07-Oct-88 2334 X3J13-mailer Issue: TAGBODY-CONTENTS (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 23:34:50 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 23:33:05 PDT
Date: 7 Oct 88 23:33 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: TAGBODY-CONTENTS (Version 4)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-233305-1841@Xerox>
!
Issue: TAGBODY-CONTENTS
References: TAGBODY (pp 130-131 of CLtL)
Category: CLARIFICATION
Edit History: 13-Sep-88, version 1 by Walter van Roggen
02-Oct-88, version 2 by Pitman
(beef up rationale, clarify tag NIL is ok)
04-Oct-88, version 3 by Pitman (fix wording bug)
05-Oct-88, version 4 by Pitman
(modify proposal based on comments from Peck@Sun
-- allow both (GO NIL) and unused duplicated tags)
Problem Description:
CLtL specifies that symbols and integers are valid tags
in a TAGBODY and that lists are valid forms in a TAGBODY
but is silent about other data types.
Also, NIL is both a symbol and a list. Some implementations
might permit (GO NIL) because they treat NIL as a tag,
while others might not permit because they treat NIL as a form.
Proposal (TAGBODY-CONTENTS:FORBID-EXTENSION):
TAGBODY treats symbols (including NIL) and integers as tags,
and treats conses as forms.
It is an error if an expression in a TAGBODY is not a symbol,
an integer, or a cons. Implementations are forbidden from
extending this syntax.
It is an error to do a GO to a tag name for which the same
(i.e., EQL) tag appears more than once in the body of the
innermost TAGBODY containing that tag.
The same restrictions apply to all forms which implicitly use
TAGBODY, such as PROG and DO.
Rationale:
The proposed set of tags is expressionally adequate.
Other obvious candidate types have lurking problems that could
lead to subtle program bugs if permitted as tags. For example,
- Characters make bad tags because, for example,
(TAGBODY ... #\Return ... #\Newline ...)
will be an error in some implementations due to
(EQL #\Return #\Newline).
- Floats make bad tags because round-off error will vary
between implementations.
- Rationals have problems with reduction to lowest terms.
eg, (EQL 1/2 2/4). This doesn't vary between implementations
but may still cause surprises.
Duplicated tags are permitted in situations where no GO is done
to them primarily for two reasons:
- To permit NIL to occur more than once in common situations
such as:
(defmacro foo1 (&rest args)
`(do () ((test-fn))
,(when (member :bar args) '(do-bar-thing))
,(when (member :baz args) '(do-baz-things))
(do-regular-things)))
- To permit the use of symbols as `dividers' between major
sections of code. eg,
(do (...)
(...)
-----
(...)
(...)
-----
(...))
It is not our intent particularly to encourage either of these
practices. Both are easy to work around. But current practice is
to permit such uses in many implementations, and there was no driving
reason to force such code to break.
Current Practice:
Symbolics Genera documents that only symbols or integers are permitted.
The restriction is enforced by the compiler, but not the interpreter.
The TI Explorer permits using NIL as a GO tag, but as a special case,
does not warn about multiple appearances of NIL.
Cost to Implementors:
A few simple checks are probably all that's needed. Probably most
implementations (both interpreters and compilers) already perform them.
Cost to Users:
Unlikely to affect any portable code.
If there are implementations which support other objects as tags
(floats, for example), there may be simple editing necessary.
Benefits:
One less place for portability problems to occur.
Aesthetics:
Makes the language description more precise.
Discussion:
This first appeared in ">GLS>clarifications.text" of 12/06/85.
Historical Note (JonL, Steele):
The reason pdp10 MacLisp allowed numbers, including flonums,
as tags was that Ira Goldstein's LLOGO (a LOGO system
written entirely in Lisp) just used READ for the statement
numbers, and they looked like floats; e.g., 1.1, 1.2, ... etc.
Pitman supports this proposal.
----- End Forwarded Messages -----
∂07-Oct-88 2343 X3J13-mailer Issue: VARIABLE-LIST-ASYMMETRY (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 23:43:45 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 23:41:38 PDT
Date: 7 Oct 88 23:41 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: VARIABLE-LIST-ASYMMETRY (Version 2)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-234138-1843@Xerox>
The only comment on this issue is that it should include
COMPILER-LET.
!
Issue: VARIABLE-LIST-ASYMMETRY
References: CLtL pgs. 110, 122, 131
Category: ADDITION
Edit history: Revision 1 by Skona Brittain 07/26/88
Revision 2 by Skona Brittain 08/04/88
Problem Description:
The syntax of items in the variable-list for various control structues
(do, let, prog and their duals) varies. This variation seems unnecessary.
The allowed variations are indicated in the following chart:
do & do*: (var) (var init) (var init step)
prog & prog*: var (var) (var init) n.a.
let & let*: var (var val) n.a.
Note that just plain `` var '' is prohibited in do forms
and that the case of ``(var)'' is prohibited in let forms.
Proposal (VARIABLE-LIST-ASYMMETRY:SYMMETRIZE):
Allow all the variations in all of the forms;
i.e. add the prohibited cases mentioned above.
I.e. change the variable-list in the syntax descriptions as follows:
do & do*: ( { var | (var [init [step]] ) }* )
let & let*: ( { var | (var [value] ) }* )
Test Cases:
(let (a (b) (c 3)) ... ) would be valid.
(do* (a (b) (c 3)) ... ) would be valid.
Rationale:
The asymmetry is unnecessary and impedes learning of CL.
Any other way to make these cases consistent, such as either
omitting just ``var'' from do & do* and prog & prog*, or
omitting ``(var)'' from let & let* and prog & prog*,
would be an incompatible change to the language.
This way just adds the flexibility found in some of the forms to all of them.
Current Practice:
KCL allows ``(var)'' in let & let* but not ``var'' in do & do*.
Symbolics Genera allows all three cases in all the forms; i.e. it conforms
to this proposal.
Cost to Implementors:
Extremely slight. (May involve subtracting code rather than adding it).
Cost to Users:
None.
Cost of Non-Adoption:
The variation in syntax makes them harder to learn.
Benefits:
Ease of learning.
Aesthetics:
Symmetry is more aesthetic than asymmetry, at least to some of us.
Discussion:
Kent supports this proposal.
The issue about whether the atomic ``var'' should be allowed at all in the
variable lists for let & let* is a separate issue. (So is whether
it should mean that the var is initially bound to nil.) Since it is allowed,
this proposal merely says that the alternative syntax of an atom within a
list with no initial value, ``(var)'', should also be allowed.
∂08-Oct-88 1021 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Thinking Machines
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Oct 88 10:21:48 PDT
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sat 8 Oct 88 10:18:02-PDT
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA15306; Sat, 8 Oct 88 09:56:29 PDT
Date: Sat, 8 Oct 88 09:56:29 PDT
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8810081656.AA15306@Tenaya.stanford.edu>
To: faculty@score
Subject: Thinking Machines
Marvin Denicoff (ex of ONR and now of Thinking Machines) and someone
from Thinking Machines will visit us on Friday, October 21 to make a
presentation about the Connection Machine. By copy of this note I'm
asking Joyce to arrange a room from 3 p.m. that day (for an
hour-and-a-half, say). Please let Joyce (chandler@polya) know if you
are definite about attending so she will be able to guess about room
size.
-Nils
∂08-Oct-88 1032 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu visitors
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Oct 88 10:32:26 PDT
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sat 8 Oct 88 10:28:37-PDT
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA15322; Sat, 8 Oct 88 10:22:09 PDT
Date: Sat, 8 Oct 88 10:22:09 PDT
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8810081722.AA15322@Tenaya.stanford.edu>
To: faculty@score, staff@score
Subject: visitors
I would like to remind everyone about the Department's procedures for
inviting and housing visitors in Margaret Jacks Hall. (Housing
visitors in Cedar, the CIS, and at Welch Road seems to be working well
under their own local procedures.)
The Department invites occasional Visiting Professors and Industrial
Professors. These are decided upon by a committee chaired this year
by Andrew Goldberg. If you have recommendations about a person that
should be invited to the CSD next year under that category, please
forward complete info to Andy. His committee will make a
recommendation to me in time for me to extend an invitation. He will
coordinate with Yvette Sloan before an invitation is made to determine
exactly where we will put such visitor(s).
Faculty members from time to time would like to invite visiting
scholars or hire Research Associates to work with them. The ground
rules for both are:
1) For all sites: If a visiting scholar is from industry, check with
Carolyn Tajnai first about our industrial visitors policy (priority is
given to Forum members and the company pays a certain amount to the
Dept. for the privilege of having the visitor here).
2) The host faculty member should be in residence during all of the
time his/her visitor is here. We simply don't have the space for
"unattached visitors."
3) Secure a definite office location with Yvette Sloan BEFORE inviting
the visitor or planning to hire a Research Associate. Space is tight,
and the Department cannot provide space for everyone who wants to
come. (There is no such thing as space that "belongs" to a research
group or to a particular faculty member in Margaret Jacks Hall!
Therefore there are no exceptions to this rule based on the faulty
premise that the invited visitor will occupy space belonging to the
host.) We continue to have some embarrasing incidents in which a
visitor "shows up" wondering where his/her office is and no plans have
been made.
In the past we have occasionally been able to smooth over problems
caused by lapses from these long-standing rules, but with growth in
the Dept. we must now husband carefully each square meter.
Thanks for your cooperation.
-Nils
∂08-Oct-88 1041 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu colloquium
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Oct 88 10:41:39 PDT
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sat 8 Oct 88 10:38:07-PDT
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA15340; Sat, 8 Oct 88 10:31:38 PDT
Date: Sat, 8 Oct 88 10:31:38 PDT
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8810081731.AA15340@Tenaya.stanford.edu>
To: faculty@score, csd@score
Subject: colloquium
We are reinstituting the CSD colloquium on a trial basis for Winter
and Spring Quarters, 1989. Jeff Eppinger is the coordinator for
Winter Quarter, Yoav Shoham for Spring Quarter. The colloquium will
take place on Tuesday afternoons from 4:15 to 5:05 (preceded by an
informal cookies and juice reception in the MJH lounge). (I trust
that Roy Jones and his staff will be securing a suitable place with TV
facilities in which to have the colloquium and arranging for the
appropriate entries in the Winter and Spring time schedules.)
If you know of visitors to the campus who would be good colloquium
speakers please inform Jeff and/or Yoav. If you plan to invite such a
visitor and can arrange the visit for a Tuesday, that would be
helpful. Colloquium speakers should also be invited to our Tuesday
faculty lunches. Search committees who want to invite candidates to
give a presentation might consider having them give a colloquium.
Thanks, -Nils
∂08-Oct-88 1150 CL-Cleanup-mailer Issue: RETURN-VALUES-UNSPECIFIED (Version 4)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 11:49:54 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Sat, 8 Oct 88 14:47:13 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Sat, 8 Oct 88 14:46:39 EDT
Date: Sat, 8 Oct 88 14:47 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: RETURN-VALUES-UNSPECIFIED (Version 4)
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu, Masinter.pa@xerox.com
In-Reply-To: <881007-211606-1727@Xerox>
Message-Id: <19881008184726.3.BARMAR@OCCAM.THINK.COM>
Date: 7 Oct 88 21:16 PDT
From: masinter.pa@xerox.com
Proposal (RETURN-VALUES-UNSPECIFIED:SPECIFY)
Clarify that the return values for the listed constructs are as follows:
CLOSE -- the stream argument.
IN-PACKAGE -- the new package, i.e. the value of *PACKAGE* after the
execution of IN-PACKAGE.
RENAME-PACKAGE -- the renamed package.
SET-SYNTAX-FROM-CHAR -- T
LOCALLY -- the return values of the last form of its body, i.e. the body is
surrounded by an implicit PROGN.
Cost to Implementors:
Small.
Benefits:
This clarification will assist users in writing portable code.
Except for LOCALLY, I don't see the point of specifying the return
values of the above functions. Yes, the cost to implementors is small,
but why bother in the first place? I think they should be made
explicitly implementation defined, like the other functions that were
listed.
If others do prefer to specify explicit return values, I agree with the
particular choices (although for SET-SYNTAX-FROM-CHAR I don't see why it
shouldn't return one of the characters).
barmar
∂08-Oct-88 1229 X3J13-mailer REPLY-TO: CL-CLEANUP@Sail.Stanford.Edu
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 12:28:58 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 12:17:28 PDT
Date: 8 Oct 88 12:17 PDT
From: masinter.pa@Xerox.COM
Subject: REPLY-TO: CL-CLEANUP@Sail.Stanford.Edu
To: Barry Margolin <barmar@Think.COM>
cc: x3j13@sail.stanford.edu
Message-ID: <881008-121728-2116@Xerox>
Barry:
I carefully typed the REPLY-TO: CL-CLEANUP@Sail.Stanford.Edu in all of the
mail to X3J13 with the idea that, if there was discussion on any of these
issues, we should handle them within cleanup. For many of the issues, there
has been a significant amount of prior discussion. We've tried for most of
the issues to at least summarize the discussion, but perhaps we've been
amiss, or have missed some points. You're welcome to participate directly
in the cleanup committee, of course.
I promise all of you that if you send comments on issues to cl-cleanup that
they will not be ignored, and that I think it is important that you are
satisfied that your concerns have at least been aired before a proposal is
voted on in the full X3J13 meeting.
Thanks,
Larry
∂08-Oct-88 1253 X3J13-mailer DRAFT Issue: CLOSED-STREAM-OPERATIONS (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 12:53:36 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 12:48:03 PDT
Date: 8 Oct 88 12:48 PDT
From: masinter.pa@Xerox.COM
Subject: DRAFT Issue: CLOSED-STREAM-OPERATIONS (Version 2)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-124803-2142@Xerox>
This issue is in discussion in the cleanup committee. The proposal is not ready for voting at X3J13. This is to inform you about the current state of discussion.
!
Status: DRAFT
Issue: CLOSED-STREAM-OPERATIONS
References: CLOSE (p 332)
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
8-Oct-88, Version 2 by Masinter
Related Issues: STREAM-CAPABILITIES, STREAM-ACCESS, STREAM-INFO
Problem Description:
The description of CLOSE is not completely clear about the functions
which are allowed to be performed on a closed stream.
On p332 it says:
"The stream is closed. No further Input/output operations may be
performed on it. However, certain inquiry operations may still
be performed, ..."
but the list of inquiry operations is not specified.
At least one implementation interpreted the list to include
at least OUTPUT-STREAM-P, while another has disallowed that operation
to be performed on a closed stream.
Proposal (CLOSED-STREAM-FUNCTIONS:DISALLOW-ALL)
Clarify that it is an error to perform any operation on a closed stream.
Rationale:
This clarification allows existing implementations to maintain the status
quo, while alerting users to the fact that the result of performing
an operation on a closed stream is undefined in the standard.
Also, the descriptions of OUTPUT-STREAM-P and INPUT-STREAM-P indicate
that these functions can only be performed on streams that have not
been closed.
Current Practice:
At least two implementations differ in which functions are allowed to be
performed on a closed stream.
Adoption Cost:
None.
Benefits:
This clarification will assist users in writing portable code.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
Closing streams is necessary for deallocation of system resources that might have been associated with their opening. Implementations and stream-types differ as to how much of the "stream information" that Lisp normally expects to be able to obtain is in the host operating system (and thus deallocated when the stream is closed) and how much is in Lisp, and presumably managed by the normal Lisp storage manager.
Closing a file stream also has the effect of allowing the file to be accessed for other operations in operating systems that implement file interlocking.
Of STREAMP, INPUT-STREAM-P, OUTPUT-STREAM-P, TRUENAME, PATHNAME, which are legitimate on closed streams?
all?
What are the effects of CLOSE on composite streams (such as broadcast, two-way, and concatinated streams?)
close constituents?
What are the effects of CLOSE on a constructed stream (e.g., WITH-OUTPUT-TO-STRING)?
no effect?
∂08-Oct-88 1320 X3J13-mailer DRAFT Issue: COERCE-INCOMPLETE (Version 1)+
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 13:19:52 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 13:09:12 PDT
Date: 8 Oct 88 13:09 PDT
From: masinter.pa@Xerox.COM
Subject: DRAFT Issue: COERCE-INCOMPLETE (Version 1)+
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-130912-2162@Xerox>
This issue is still under debate and the writeup below is very rough. We think that TYPE-OF-UDERSPECIFIED might help make the issue clearer.
We do not expect to discuss this issue in the full X3J13 session. This is just for your information that we're discussing the topic.
!
Status: DRAFT
Issue: COERCE-INCOMPLETE
Reference: coerce (CLtL p50)
Category: change
Edit history: version 1 by M.Ida, 26-Feb-1988
Problem Description:
--------------------
Problem 1:
Coerce is not symmetric or not generic among data types.
In CLtL, Coerce is defined in page 50 and 51 that,
1) a sequence type may be converted to any other sequence type.
2)Some strings, symbols, and integers may be converted to characters.
2-1) If object is a string of length 1,
then the sole element of the string is returned.
2-2) If object is a symbol whose print name is of length 1,
then the sole element of the print name is returned.
2-3) If object is an integer n,
then (int-char n) is returned.
3) any non-complex number can be converted to a XXX-float.
4) any number can be converted to a complex number.
The next table shows that how coerce is not symmetric among character,
string, symbol and integer.
TABLE 1. Possible Conversions among character, string,symbol, integer
type of conversion provided functions coercion under the CLtL
character -> string string X
character <- string coerce (if the string has only one char.) O
character -> symbol (intern (string @i[ch])) X
character <- symbol coerce (if pname length is 1) O
character -> integer char-code, char-int X
character <- integer code-char (zero font-, zero bits- attrib.) O
int-char (any font- and any bits-)
string -> symbol intern, make-symbol X
string <- symbol string, symbol-name X
string -> integer (char-code (coerce @i[string] 'character)) X
string <- integer (string (code-char @i[integer])) X
symbol -> integer (char-code (coerce @i[symbol] 'character)) X
symbol <- integer (intern (string (code-char @i[integer]))) X
Problem 2:
The function of coerce for character is defined to act as char-int/int-char
not as char-code/code-char.
Proposal: Coerce :replace
-------------------------
COERCE should be more generalized for string, symbol, integer, and character
data types. The observations show there are
no problem if extensions are fully written out in the details.
Here is an extension to the current coerce definition using the CLOS.
(defmethod coerce ((x character) (y (eql string))) (string x))
(defmethod coerce ((x character) (y (eql symbol))) (intern (string x)))
(defmethod coerce ((x character) (y (eql integer))) (char-code x))
(defmethod coerce ((x string) (y (eql symbol))) (intern x))
(defmethod coerce ((x symbol) (y (eql string))) (string x))
(defmethod coerce ((x string) (y (eql integer)))
(char-code (coerce x 'character)))
(defmethod coerce ((x integer) (y (eql string))) (string (code-char x)))
(defmethod coerce ((x symbol) (y (eql integer)))
(char-code (coerce x 'character)))
(defmethod coerce ((x integer) (y (eql symbol)))
(intern (sting (code-char x))))
(defmethod coerce ((x integer) (y (eql character)))
(code-char x)) ; redefinition. CLtL defines as int-char
The keys are
a) ignore char-bits and char-font upon the conversion of characters,
assuming font-attribute will be flushed from the language spec.
b) ignore the package name upon the conversion of symbols.
(package name has no role upon the conversion.)
c) the created symbol will be interned to the current package.
Rationale:
----------
By extending the definition as this document suggests, the functionality
of coerce is symmetric among characters, strings, symbols and integers.
Current Practice:
Cost to implementors:
Cost to users:
Benefits:
Aesthetics:
Discussion:
<<discussion from original Common Lisp design.>>
Making COERCE symmetric would probably be a bad idea, e.g., that it can coerce
from INTEGER to FLOAT and not from FLOAT to INTEGER is on purpose.
We think COERCE from integer to character is odd and non-portable and think it
perhaps should be removed from the standard.
COERCE from character to STRING is a good idea.
We are now puzzled by the inconsistency of (COERCE x 'STRING) vs (STRING x) and
want to reduce it.
We would like (COERCE x 'PATHNAME) to work like (PATHNAME x).
The reason that (COERCE symbol 'STRING) is difficult is that (COERCE 'NIL
'STRING) as a symbol could return "NIL", but (COERCE '() 'STRING) as the empty
list could return "".
FUNCTION-TYPE has extended COERCE to work for 'FUNCTION.
(COERCE "5" 'INTEGER)
should return integer.
!
Issue: COERCE-FROM-TYPE
References: COERCE (p51)
Related-Issues: COERCE-INCOMPLETE
Category: ADDITION
Edit history: 20-Jun-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
COERCE is difficult to extend because ambiguities arise about the
source type of the coercion.
For example, should (COERCE NIL 'STRING) return "" or "NIL".
The choice would be arbitrary unless you knew whether NIL was being
viewed as an empty list or a symbol.
Similarly, (COERCE (CHAR-CODE #\A) 'STRING) might return the same
as (FORMAT NIL "~D" (CHAR-CODE #\A)) -- "65" in most ASCII-based
implementations -- or it might return "A", depending on whether the
result of char-code was viewed as a number or more specifically as
a character code.
Proposal (COERCE-FROM-TYPE:NEW-ARGUMENT):
Add an extra optional argument to COERCE which specifies the type
from which the coercion is to be done. The new syntax would be:
COERCE object to &optional (from (TYPE-OF object))
Constrain that FROM must be such that (TYPEP OBJECT FROM) is true.
Rationale:
This leaves room for a subsequent proposal to extend COERCE in
interesting ways. For example, extensions such as the following
might be considered:
(COERCE NIL 'STRING 'LIST) => ""
(COERCE NIL 'STRING 'SYMBOL) => "NIL"
A new type CHAR-CODE might even be introduced as
(DEFTYPE CHAR-CODE () `(INTEGER 0 (,CHAR-BITS-LIMIT)))
so that COERCE could handle cases like:
(EQUAL (COERCE (CHAR-CODE #\A) 'STRING 'NUMBER)
(FORMAT NIL "~D" (CHAR-CODE #\A))) => T
(COERCE (CHAR-CODE #\A) 'STRING 'CHAR-CODE) => "A"
Such specific proposals are deliberately not part of this proposal
in order to separate the general purpose mechanism from the more
specific details.
Current Practice:
Probably no one implements the proposed behavior at this time.
Cost to Implementors:
The more optimization a compiler does (or might do) of COERCE, the more
work might be necessary. In general, however, the changes would probably
not involve a major amount of work.
Cost to Users:
This change is upward compatible.
Cost of Non-Adoption:
Various proposals to extend COERCE would probably not pass because
not everyone can agree on how to view the type of the first argument.
!
M.Ida responds
My primary points are on the relation to CLOS and the simplicity which
might be obtained as a result of the integration.
I further thought that coerce can be viewed as a generic function
(I know recent talk of the mailing list for this).
So I thought it is possible to define for the ambiguous cases
consulting type hierarchy related things in CLOS.
For the above example, since CLOS defines the class precedence list for NULL
as (null symbol list sequence t),
(coerce nil 'string) should be "NIL" first if there are no special methods.
I had thought that COERCE should grow up into a kind of universal function.
But I realized that the current role of COERCE seems to be a very low level primitive.
Possibilities:
extend coerce to handle more types?
Add an extra argument?
Make COERCE generic?
Make COERCE take classes as well as type names?
∂08-Oct-88 1329 X3J13-mailer DRAFT Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 13:29:14 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 13:25:27 PDT
Date: 8 Oct 88 13:25 PDT
From: masinter.pa@Xerox.COM
Subject: DRAFT Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)
To: x3J13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-132527-2172@Xerox>
There have been last-minute edits to the wording (but not the intent) of this issue/proposal that cause me to write DRAFT in the issue status.
!
Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
References: Data types and Type specifiers: CLtL p. 11; Sect. 4.5, p.45
TYPEP and SUBTYPEP; CLtL Sect. 6.2.1, p.72
ARRAY-ELEMENT-TYPE, CLtL p. 291
The type-specifiers ARRAY, COMPLEX, SIMPLE-ARRAY, and VECTOR
Related Issues: SUBTYPEP-TOO-VAGUE, LIST-TYPE-SPECIFIER
Category: CHANGE
Edit history: Version 1, 13-May-88, JonL
Version 2, 23-May-88, JonL
(typo fixes, comments from moon, rearrange some discussion)
Version 3, 02-Jun-88, JonL
(flush alternate proposal ["flush-upgrading"]; consequently,
move more of discussion back to discussion section.
Version 4, 01-Oct-88, Jan Pedersen & JonL
(reduce discussion, and "cleanup" wordings)
(Version 5 edit history missing)
Version 6, 6-Oct-88, Moon
(fix typos, cover subtypep explicitly, add complex,
change name of UPGRADE-ARRAY-ELEMENT-TYPE)
Version 7, 7-Oct-88, JonL (more name and wording changes)
Version 8, 8-Oct-88, Masinter (wording, discussion)
Problem description:
CLtL occasionally draws a distinction between type-specifiers "for
declaration" and "for discrimination". Many people are confused by
this situation. A consequence of this distinction is that a variable
declared to be of type <certain-type> and all of whose assigned objects
are created in accordance with that type, may still have none of its
values ever satisfy the TYPEP predicate with that type-specifier.
One type-specifier with this property is
(ARRAY <element-type>)
for various implementation dependent values of <element-type>. For
example, in most implementations of CL, an array X created with an
element-type of (SIGNED-BYTE 5) will, depending on the vendor, either
satisfy
(TYPEP X '(ARRAY (SIGNED-BYTE 8))), or
(TYPEP X '(ARRAY T))
but (almost) never will it satisfy
(TYPEP X '(ARRAY (SIGNED-BYTE 5))).
Proposal: (ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING)
Summary of changes:
Eliminate the distinction between type-specifiers "for declaration" and
"for discrimination". Change the meaning of the <element-type> in the
ARRAY type-specifier and its subtypes, and in the COMPLEX type-specifier,
to be the same for TYPEP and SUBTYPEP as for TYPE declarations.
Specify how SUBTYPEP behaves on these type-specifiers. Add a function
to provide access to the implementation-dependent set of array types
and another function to provide access to the implementation-dependent
set of complex number types.
Specifics:
1. Eliminate references to the distinction between types "for declaration"
and "for discrimination" in the discussion of array and complex
type-specifiers. This would include documentation patterned after CLtL:
a.) The discussion in section 4.5, pp. 45-7
b.) p. 291, the sentence begining "This set may be larger than the set
requested when the array was created; for example . . ."
Instead, (ARRAY <type>) always means all arrays that can result by specifying
<type> as the :ELEMENT-TYPE argument to the function MAKE-ARRAY, and
(COMPLEX <type>) always means all complex numbers that can result by
giving numbers of type <type> to the function COMPLEX, plus all other
complex numbers of the same specialized representation.
2. Change the meaning of (TYPEP <x> '(ARRAY <type>)) to be true if and
only if <x> is an array of the most specialized representation capable
of holding elements of type <type>. In other words, it is true if and
only if <x> is an array and (ARRAY-ELEMENT-TYPE <x>) is type-equivalent
to (ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE <type>)).
Do the same for SIMPLE-ARRAY and VECTOR.
3. Change the meaning of (TYPEP <x> '(COMPLEX <type>)) to be true if
and only if <x> is a complex number of the most specialized
representation capable of holding parts of type <type>, or if <x> is of
any subtype of that representation. Both the real and imaginary parts
must satisy (TYPEP <real-or-imag-part> '<type>).
4. Define that for all type-specifiers <type1> and <type2>, other than *,
(ARRAY <type1>) and (ARRAY <type2>) are either equivalent or disjoint,
depending on whether they use the same specialized representation or
distinct representations. This defines the behavior of SUBTYPEP.
5. Define that for all type-specifiers <type1> and <type2>, other than *,
(SUBTYPEP '(COMPLEX <type1>) '(COMPLEX <type2>)) is T T if they use the
same specialized representation, T T if they use distinct specialized
representations but (SUBTYPEP '<type1> '<type2>) is true, and NIL T
otherwise.
6. Require that the resultant ARRAY-ELEMENT-TYPE from a call to
MAKE-ARRAY is independent of any argument to MAKE-ARRAY except for the
:ELEMENT-TYPE argument. Thus the set of specialized array
representations must be consistent between single-dimensional and
multi-dimensional, simple and non-simple, short and long arrays.
7. Add the function IMPLEMENTED-ARRAY-ELEMENT-TYPE of one argument
which returns the same result as:
(DEFUN IMPLEMENTED-ARRAY-ELEMENT-TYPE (TYPE)
(ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE TYPE)))
The type specifiers (ARRAY <type1>) and (ARRAY <type2>), where neither
<type1> nor <type2> is *, are equivalent if <type1> and <type2> produce
the same value from IMPLEMENTED-ARRAY-ELEMENT-TYPE, and disjoint
otherwise.
8. Add the function IMPLEMENTED-COMPLEX-PART-TYPE of one argument
which returns the part type of the most specialized complex number
representation that can hold parts of the given argument type.
Test cases:
Let <aet-x> and <aet-y> be two distinct type specifiers that are
definitely not type-equivalent in a given implementation, but for which
make-array will return an object of the same array type. This will be
an implementation dependent search, but in every implementation that
the proposer has tested, there will be some such types; often,
(SIGNED-BYTE 5) and (SIGNED-BYTE 8) will work.
Thus, in each case, both of the following forms return T T:
(subtypep (array-element-type (make-array 0 :element-type '<aet-x>))
(array-element-type (make-array 0 :element-type '<aet-y>)))
(subtypep (array-element-type (make-array 0 :element-type '<aet-y>))
(array-element-type (make-array 0 :element-type '<aet-x>)))
To eliminate the distinction between "for declaration" and "for
discrimination" both of the following should be true:
[A]
(typep (make-array 0 :element-type '<aet-x>)
'(array <aet-x>))
(typep (make-array 0 :element-type '<aet-y>)
'(array <aet-y>))
Since (array <aet-x>) and (array <aet-y>) are different names for
exactly the same set of objects, these names should be type-equivalent.
That implies that the following set of tests should also be true:
[B]
(subtypep '(array <aet-x>) '(array <aet-y>))
(subtypep '(array <aet-y>) '(array <aet-x>))
Additionally, to show that un-equivalent type-specifiers that use the
same specialized array type should be equivalent as element-type
specifiers, the following type tests should be true:
[C]
(typep (make-array 0 :element-type '<aet-y>)
'(array <aet-x>))
(typep (make-array 0 :element-type '<aet-x>)
'(array <aet-y>))
Rationale:
This proposal legitimizes current practice, and removes the obscure and
un-useful distinction between type-specifiers "for declaration" and
"for discrimination". The suggested changes to the interpretation of
array and complex type-specifiers follow from defining type-specifiers
as names for collections of objects, on TYPEP being a set membership
test, and SUBTYPEP a subset test on collections of objects.
The small differences between the specification for ARRAY and the
specification for COMPLEX are necessary because there is no creation
function for complexes which allows one to specify the resultant type
independently of the types of the parts. Thus in the case of COMPLEX
we must refer to the type of the two parts, and to the fact that a
number can be a member of more than one type. Note that:
(SUBTYPEP '(COMPLEX SINGLE-FLOAT) '(COMPLEX FLOAT))
is true in all implementations, but
(SUBTYPEP '(ARRAY SINGLE-FLOAT) '(ARRAY FLOAT))
is only true in implementations that do not have a specialized array
representation that can hold single-floats but not other floats.
Current Practice:
Every vendor's implementation that the proposer has queried has a
finite set of specialized array representations, such that two
non-equivalent element types can be found that use the same specialized
array representation; this includes Lucid, Vaxlisp, Symbolics, Franz,
and Xerox. Most implementations fail tests [A] and [C] part 1, but pass
tests [A] and [C] part 2; this is a consequence of implementing the
distinction between "for declaration" and "for discrimination". Lucid
and Xerox both pass test [B], and the other implementations fail it.
No vendor that the proposer has queried has any specialized representation
for complexes.
Cost to Implementors:
This proposal is an incompatible change to the current language
specification, but only a small amount of work should be required in
each vendor's implementation of TYPEP and SUBTYPEP.
Cost to Users:
Because of the prevalence of confusion in this area, it seems unlikely
that any user code will have to be changed. In fact, it is more likely
that some of the vendors will cease to get bug reports about MAKE-ARRAY
returning a result that isn't of "the obvious type". Since the change
is incompatible, some user code might have to be changed.
Cost of non-adoption:
Continuing confusion in the user community.
Benefits:
It will greatly reduce confusion in the user community. The fact that
(MAKE-ARRAY <n> :ELEMENT-TYPE '<type>) frequently is not of type
(ARRAY <type>) has been very confusing to almost everyone.
Portability of applications will be increased slightly, since
the behavior of
(TYPEP (MAKE-ARRAY <n> :ELEMENT-TYPE <type>) '(ARRAY <type>))
will no longer be implementation-dependent.
Esthetics:
Reducing the confusing distinction between type-specifiers "for
declaration" and "for discrimination" is a simplifying step -- it is a
much simpler rule to state that the type-specifiers actually describe
the collections of data they purport to name. Thus this is a step
towards increased elegance.
Discussion:
This issue was prompted by a lengthy discussion on the Common Lisp
mailing list. It was the subject of a lengthy discussion in the
cleanup committee, as well as a number of individual efforts.
We considered the possibility of requiring that arrays remember
the element-type given in the make-array call, e.g., require that
(equal <x> (array-element-type (make-array <n> :element-type <x>)))
for all valid type specifiers <x>. This has several problems: it
increases the storage requirement for arrays, and 'hides' a
relevant part of the underlying implementation for no apparently
good reason. In addition, there might be some problems with
equivalent but separate types (although this might be handled
by changing "equal" to "equal-type", given a more rigorous
definition of SUBTYPEP; see issue SUBTYPEP-TOO-VAGUE.)
However, it would increase portability, since it would be much
more difficult to write a program that, for example, created
an array with one element-type and then assumed an upgraded
element-type. It would be valid for an implementation to do so
-- to remember the original array element-type or its canonical
or expanded form -- and satisfy all of the constraints of this
proposal.
We considered a suggestion to restrict the set of "known" array
element types; this would gain portability at the expense of limiting
the language.
----- End Forwarded Messages -----
∂08-Oct-88 1441 X3J13-mailer DRAFT Issue: DEFPACKAGE (version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 14:41:30 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 14:39:27 PDT
Date: 8 Oct 88 14:39 PDT
From: masinter.pa@Xerox.COM
Subject: DRAFT Issue: DEFPACKAGE (version 6)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-143927-2237@Xerox>
This issue is only marked DRAFT because there were some last minute edits
to it.
!
Issue: DEFPACKAGE
References: CLtL section 11.7.
Issue: IN-PACKAGE-FUNCTIONALITY
Category: ADDITION
Edit history: Version 1, 12-Mar-88, Moon
Version 2, 23-Mar-88, Moon, changes based on discussion
Version 3, 27-Sep-88, JonL
(remove :import, :shadowing-import; allow :export to work on
imported and inherited; update references to in-package, etc.)
Version 4, 1-Oct-88, Masinter
Version 5, 6-Oct-88, Moon
Version 6, 8-Oct-88, JonL (little nits)
Problem description:
The package functions included in CLtL encourage a programming style
that tends to evoke the worst aspects of the package system. The
problem is that if the definition of a package is scattered through
a program, as a number of individual forms, it is very easy to read
a symbol before the package setup needed to read that symbol correctly
has been accomplished. Three examples: an inherited symbol that should
have been shadowed might be accessed; a single-colon prefix might be
used for a symbol that will later be exported, causing an error; a local
symbol might be accessed where a symbol that will later be imported or
inherited was intended. These problems can be difficult to understand
or even to recognize, are difficult to recover from without completely
restarting the Lisp, and frustrating to programmers.
Proposal (DEFPACKAGE:ADDITION):
Add a DEFPACKAGE macro to the language. In the description below,
'package-name' and 'symbol-name' can be a symbol or a string; if a symbol,
only its name matters, not what package it is in.
The syntax of DEFPACKAGE is
(DEFPACKAGE package-name {option}*)
where each option is a list of a keyword and arguments. Nothing in a
DEFPACKAGE form is evaluated.
Standard options for DEFPACKAGE are listed below. Options may appear
more than once (useful mainly for :IMPORT-FROM and :SHADOWING-IMPORT-FROM).
It is an error to specify :SIZE more than once.
(:NICKNAMES {package-name}*)
Set the package's nicknames to the specified names.
(:USE {package-name}*)
The package is to "use" the other designated packages; that is,
it will inherit from them.
(:SHADOW {symbol-name}*)
Create the specified symbols in the package being defined,
making them shadows, just at the function SHADOW would do.
(:SHADOWING-IMPORT-FROM package-name {symbol-name}*)
Find the specified symbols in the specified package and import
them into the package being defined, and place them on the
shadowing symbols list. In no case will
symbols be created in any package other than the one being defined;
a continuable error is signalled if no symbol is accessible in the
package named package-name for one of the symbol-names.
(:IMPORT-FROM package-name {symbol-name}*)
Find the specified symbols in the specified package and import
them into the package being defined. In no case will
symbols be created in a package other than the one being defined;
a continuable error is signalled if no symbol is accessible in the
package named package-name for one of the symbol-names.
(:INTERNAL {symbol-name}*)
Find or create symbols with the specified names. This is useful
if a :IMPORT-FROM or :SHADOWING-IMPORT-FROM option in a later
DEFPACKAGE for another package expects to find these symbols,
but the symbols are not to be exported.
(:EXPORT {symbol-name}*)
Find or create symbols with the specified names and export them.
Note an interaction with the :USE option, since intern'ing may inherit
symbols rather than creating new ones; note also an interaction
with the :INTERNAL, :IMPORT-FROM and :SHADOWING-IMPORT-FROM options,
since intern'ing will merely access an already imported symbol.
(:SIZE integer)
Declare the approximate number of symbols expected in the package.
This is an efficiency hint only, so that the package's table will
not have to be frequently re-expanded when new symbols are added
to it (e.g., by reading in a large file "in" that package.)
Additional options might be allowed by an implementation; all
implementations should signal an error if an option not recognized by
that implementation is present.
The collection of symbol-name arguments given to the options :SHADOW,
:INTERNAL, :IMPORT-FROM, and :SHADOWING-IMPORT-FROM must all be
disjoint; an error is signalled otherwise. The :EXPORT option can
be thought of as occuring after all the other options have been
executed, since it may reference names found in "used" packages,
or found in the argument lists to a :SHADOW, :INTERNAL, :IMPORT-FROM,
or :SHADOWING-IMPORT-FROM option.
DEFPACKAGE creates the package as specified, and returns it as its value.
It has no other side effects; i.e., it does not do an IN-PACKAGE.
If a package with the specified name already exists, the existing package
is modified by possibly adding to its attributes. An attempt to re-define
a package with a smaller set of attributes should signal a continuable error;
at most one such error is to be signalled per call to DEFPACKAGE, regardless
of how many attributes are being re-tracted; upon continuation, the package
is created with exactly as specified.
Examples:
;;; An example which "plays it super-safe", by using only strings as names;
;;; does not even assume that the package it is read in to "uses" LISP;
;; *never* creates any symbols whatsoever in the package that it is read
;; in to.
(LISP:DEFPACKAGE "MY-PACKAGE"
(:NICKNAMES "MYPKG" "MY-PKG")
(:USE "LISP")
(:SHADOW "CAR" "CDR")
(:SHADOWING-IMPORT-FROM "VENDOR-COMMON-LISP" "CONS")
(:IMPORT-FROM "VENDOR-COMMON-LISP" "GC")
(:EXPORT "EQ" "CONS" "FROBOLA")
)
;;; A similar call, mostly using symbols rather than strings as names.
;;; Expects to be read in to a package that "uses" LISP, and *may* create
;;; random internal symbols in that package (such as MY-PACKAGE etc).
(defpackage my-package
(:nicknames mypkg :MY-PKG) ;remember CL conventions for case
(:use lisp) ; conversion on symbols
(:shadow CAR :cdr #:cons)
(:export "CONS") ;yes, this is the shadowed one.
)
Rationale:
The availability of DEFPACKAGE encourages putting the
entire definition of a package in a single place. It also encourages
putting all the package definitions of a program in a single file, which
can be loaded before loading or compiling anything that depends on those
packages. This file can be read in the USER package, avoiding any
package bootstrapping issues.
In addition, DEFPACKAGE allows a programming environment to process
the whole package setup as a unit, providing better error-checking and
more assistance with package problems, by dint of global knowledge of
the package setup.
Current practice:
Symbolics Common Lisp has always had a DEFPACKAGE, and uses it in
preference to individual calls to EXPORT, IMPORT, SHADOW, etc. The SCL
version of DEFPACKAGE has quite a few additional options, but none of them
appear to be necessary to propose for Common Lisp at this time. This
proposal is incompatible with Symbolics DEFPACKAGE in some ways that
will probably not cause major problems.
Cost to Implementors:
Small; DEFPACKAGE can be implemented simply as a bunch of
calls to existing functions.
Cost to Users:
Small, this is upward compatible.
Cost of non-adoption:
Packages continue to be difficult to use correctly.
Benefits:
Guide users away from using packages in ways that get them into trouble.
Esthetics:
Neutral.
Discussion:
The "Put in seven extremely random user interface commands" mnemonic
described in CLtL p.191 could be removed, and the special compiler
handling of these functions necessary to support that could be removed
(except possibly for REQUIRE and PROCLAIM -- see the compiler Issue
PROCLAIM-ETC-IN-COMPILE-FILE). As this would be an incompatible change,
it is not part of this proposal.
The issue IN-PACKAGE-FUNCTIONALITY recommends that IN-PACKAGE be
incompatibly changed to recognize only existing packages, not to create
them. IN-PACKAGE would then not accept any keyword arguments.
The function MAKE-PACKAGE might also be extended to take all the keywords
that DEFPACKAGE does. This could be the subject of a separate cleanup.
The macroexpansion of DEFPACKAGE can usefully canonicalize
into the strings-as-name form, so that even though the source file
showed random symbols in the DEFPACKAGE form, the compiled file might
have only strings in it.
Frequently additional implementation-dependent options take the
form of a keyword standing by itself as an abbreviation for a list
(keyword T); this syntax should be properly reported as an unrecognized
option in implementations that do not support it.
Note that we now have three continuable errors being specified, but have
not specified the condition names. This ought to be remedied.
∂08-Oct-88 1547 X3J13-mailer DRAFT Issue: DEFSTRUCT-REDEFINITION (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 15:47:25 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 88 15:44:14 PDT
Date: 8 Oct 88 15:44 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: DEFSTRUCT-REDEFINITION (Version 1)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-154414-2285@Xerox>
This issue is a draft; we need to sort out the nature of
what happens if you redefine a DEFSTRUCT with accessors
that were previously compiled, old instances, etc.
Presumably there is no groundswell for eliminating DEFSTRUCT
in favor of DEFCLASS.
!
Issue: DEFSTRUCT-REDEFINITION
References:
Category: CLARIFICATION
Edit history: Revision 1 by Skona Brittain 07/26/88
Problem Description:
The case of a structure type being redefined is not discussed in CLtL.
Proposal (DEFSTRUCT-REDEFINITION:ERROR-ITSELF):
It is an error to redefine a structure.
Proposal (DEFSTRUCT-REDEFINITION:ERROR-IFF-OLD-USE):
Redefining a structure is ok but it is an error to access, in any way,
an instance of the structure that was created prior to the redefinition.
This applies to instances of other structures that :INCLUDEd the
redefined structure.
It is also an error to use any of the redefined structures accessors
on any instances of a structure that :INCLUDEd the previous definition.
Test Cases:
(I)
(defstruct struc1
slot1 slot2)
(setq s (make-struc1 :slot1 1 :slot2 2))
(defstruct struc1 ; this is an error according to ERROR-BY-ITSELF
slot2 slot1) ; but not according to ERROR-IFF-USE
(struc1-slot1 s) ; this is an error according to ERROR-IFF-USE
(II)
(defstruct struc1
slot1 slot2)
(defstruct (struc2 (:include struc1))
slot 3)
(defstruct struc1
slot2 slot1)
(setq s (make-struc2 :slot1 1 :slot2 2))
(struc1-slot1 s) ; this is an error according to ERROR-IFF-USE
Rationale:
The issue of redefinition should be addressed since there are always
consequences that affect use of the structures: at the very least,
the constructor function gets overwritten when a structure is redefined.
ERROR-BY-ITSELF is simpler, but ERROR-IFF-USED is more amenable to use.
Current Practice:
None of KCL, Lucid, & Symbolics detect a redefinition, but all of them
return 2 as the value of the last forms in each of the above test case sets.
Cost to Implementors:
ERROR-ITSELF: none if not signaled. extremely slight if signaled.
ERROR-IFF-OLD-USE: none if not signaled. much more if signaled.
Cost to Users:
ERROR-ITSELF: It can be quite inconvenient to be prevented from "correcting"
a structure definition, which would presumably happen if the error were
signaled.
ERROR-IFF-OLD-USE: None.
Cost of Non-Adoption:
Confusion.
Benefits:
Clarity.
Aethetics:
Something that is not well-defined and leads to erratic behavior
should be explicitly considered an error.
Discussion:
Larry supports ERROR-BY-ITSELF, "in that slot-accessors for structures are
presumed to be declared "inline". If users want more flexibility than that,
they should use defclass."
Various inbetween proposals are possible, such as only incompatible
redefinitions cause errors, but they're too hard to define.
My feeling is that it's a cop-out to just say it's an error to redefine
a structure but then never signal the error - users will still be confused
by the differing seemingly erratic behavior and code.
-- - - Additional Comments - - -
"Portable programs should not dynamically redefine structures.
Programming environments are allowed, encouraged, etc. to allow such
redefinition, perhaps with warning messages. It is beyond the scope of the
language standard to define those interactions, except to note that they are not
portable.
I don't think it is a cop-out. I certainly don't want an error to be signalled.
I'm lacking a good terminology for describing the "is an error" situation that I
think this should be."
"Why not "is non-portable"?"
"We might want to at least reference the redefintion protocol of CLOS"
∂08-Oct-88 1605 X3J13-mailer Issue: DESCRIBE-INTERACTIVE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 16:05:44 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 16:01:29 PDT
Date: 8 Oct 88 16:01 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: DESCRIBE-INTERACTIVE (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-160129-2301@Xerox>
It seems unlikely that the cleanup committee actually has
more to say on this issue.
!
Issue: DESCRIBE-INTERACTIVE
References: DESCRIBE (p441)
Category: CLARIFICATION/CHANGE
Edit history: 12-Sep-88, Version 1 by Pitman
23-Sep-88, Version 2 by Masinter
Problem Description:
CLtL is not clear about whether DESCRIBE may be interactive.
While CLtL describes INSPECT as an interactive as an
interactive version of DESCRIBE, it doesn't make explicit
that DESCRIBE is non-interactive. In some implementations it is,
and in other implementations it is not.
Users of systems in which DESCRIBE is not interactive may presume
that it is safe to call DESCRIBE in a batch applications without
hanging the application, which can lead to problems.
Proposal (DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE):
Specify that DESCRIBE is permitted (though not required) to
require user input, and that such input should be negotiated
through *QUERY-IO*.
Descriptive information would continue to go to *STANDARD-OUTPUT*.
Test Case:
The following kind of interaction would be permissible in
implementations which chose to do it:
(DEFVAR *MY-TABLE* (MAKE-HASH-TABLE))
(SETF (GETHASH 'FOO *MY-TABLE*) 1)
(SETF (GETHASH 'BAR *MY-TABLE*) 2)
(SETF (GETHASH 'FOOBAR *MY-TABLE*) 3)
(DESCRIBE *MY-TABLE*)
#<EQ-HASH-TABLE 259> has 3 entries.
Do you want to see its contents? (Yes or No) Yes
Rationale:
This validates current implementations.
Current Practice:
Symbolics Genera asks some questions interactively when describing
some kinds of structured data structures, such as hash tables.
Since users can define their own DESCRIBE methods and took their cue
from the system, describing some user structures also require such
interactions.
Cost to Implementors:
None.
Cost to Users:
User code which depended on DESCRIBE running without user interaction
would have to be modified. Such code is not currently fully portable,
however.
Cost of Non-Adoption:
Users would not know the straight story about whether they should
expect interaction from DESCRIBE.
Benefits:
Implementations which don't do interactive querying in DESCRIBE only
because their not 100% sure it's kosher would be free to do it.
Aesthetics:
Some people might think it's not aesthetic for DESCRIBE to require user
intervention. Not saying whether it's permissible is probably less
aesthetic, though.
Discussion:
Pitman thinks it's important to clarify this issue, but he isn't fussy
about the particulars.
This proposal is the minimal proposal for compatibility with current
behavior.
It might be possible to extend DESCRIBE to have additional
keywords (:VERBOSE, :INTERACTIVE-ALLOWED) to cover
additional behavior.
Some members of the cleanup committee think that this is really
a change from the intent of CLtL. However, the current sentiment
is to be less rather than more specific about the behavior of debugging
tools (25.3 of CLtL).
∂08-Oct-88 1651 X3J13-mailer Issue: EXIT-EXTENT (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 16:50:55 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 16:45:27 PDT
Date: 8 Oct 88 16:45 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: EXIT-EXTENT (Version 3)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-164527-2328@Xerox>
I think it is unlikely that the cleanup committee will
have much more to say on the issue.
!
Issue: EXIT-EXTENT
References: CATCH, THROW,
BLOCK, RETURN, RETURN-FROM,
TAGBODY, GO, UNWIND-PROTECT,
Dynamic extent (CLtL p.37),
Nested dynamic extents (CLtL p.38),
Blocks can only be exited once (CLtL p.120),
Catch is disestablished just before the values
are returned (CLtL p.139).
Cleanup issue UNWIND-PROTECT-NON-LOCAL-EXIT is superseded
by this one.
Category: CLARIFICATION
Edit history: Version 1, 5-Sep-88, by Moon, for discussion
Version 2, 1-Oct-88, by Masinter, minor edits
Version 3, 7-Oct-88, by Moon, wording improvements
Problem description:
CLtL does not specify precisely when the dynamic extent (lifetime)
of a nonlocal exit such as a CATCH, BLOCK, or TAGBODY ends.
There are three cases of interest:
(1) Normal exit from a CATCH, BLOCK, or TAGBODY, or equivalent such as
PROG. A normal exit occurs when the last form in the body of one of
these constructs completes its evaluation without performing a transfer
of control. (According to CLtL p.125, there is no possibility of a
normal exit from DO.)
(2) Nonlocal exit from the target of a THROW or RETURN. A nonlocal exit
occurs when control is transferred by THROW, RETURN, or RETURN-FROM.
The CATCH or BLOCK named in the THROW, RETURN, or RETURN-FROM is
referred to as the target. The TAGBODY containing the tag named by a
GO is also referred to as the target, but GO differs from the other
nonlocal control transfer operators because GO does not exit its target.
(3) Abandonment of an exit passed over by THROW, RETURN, or GO. A
CATCH, BLOCK, or TAGBODY that is dynamically nested inside the target of
a nonlocal transfer of control is said to be passed over when control is
transferred to the target. The target itself is not said to be passed
over.
The terms "normal exit", "target", and "passed over" will be used with
these meanings for the remainder of the discussion.
CLtL is unambiguous about case 1. In case 2, the extent could end
anywhere from the time the THROW or RETURN commences, until the time the
transfer of control is completed. In case 3, the extent could end
anywhere from the time the THROW, RETURN, or GO commences, until the
time the transfer of control is completed. In case 2, it is clear that
the extent of the target ends before the transfer of control completes,
since a block cannot be exited twice, but it is not made clear whether
the extent ends before or after execution of UNWIND-PROTECT cleanup
forms. CLtL says nothing about case 3, although a note on p.38 implies
that the extent of a passed-over exit should end no later than the end
of the extent of the target exit. It would make sense for the extent
of an exit passed-over by GO to end no later than when the transfer of
control is completed, but CLtL says nothing about this.
Proposal (EXIT-EXTENT:MINIMAL):
The dynamic extent of an exit, whether target or passed-over, ends as
soon as the THROW, RETURN, or GO commences. In the language of the
implementation note on p.142, the extent ends at the beginning of the
second pass. It is an error for an UNWIND-PROTECT cleanup form executed
during a nonlocal transfer of control to attempt to use an exit whose
dynamic extent ended when the nonlocal transfer of control commenced.
This proposal is called "minimal" because it gives exits the smallest
extent consistent with CLtL.
Test Cases/Examples:
Each of the following programs is an error:
(funcall (block nil #'(lambda () (return)))) ;case 1
(block nil ;case 2
(unwind-protect (return)
(return)))
(block a ;case 3
(block b
(unwind-protect (return-from a)
(return-from b))))
(let ((a nil)) ;case 1
(tagbody t (setq a #'(lambda () (go t))))
(funcall a))
(funcall (block nil ;case 3
(tagbody a (return #'(lambda () (go a))))))
(catch nil ;case 2
(unwind-protect (throw nil t)
(throw nil t)))
(catch 'a ;case 3
(catch 'b
(unwind-protect (throw 'a t)
(throw 'b t))))
The above program is an error because the catch of b is passed over by
the first throw, hence portable programs must assume its dynamic extent
is terminated. The catch is not yet disestablished and therefore it
is the target of the second throw.
The following program is not an error. It returns 10. The inner
catch of a is passed over, but this is not case 3 because that catch
is disestablished before the throw to a is executed.
(catch 'a
(catch 'b
(unwind-protect (1+ (catch 'a (throw 'b 1)))
(throw 'a 10))))
Rationale:
Giving exits the smallest extent consistent with CLtL maximizes freedom
for implementations; there are few applications, if any, that require a
longer extent.
Current practice:
Both implementations of Symbolics Genera (3600 and Ivory) end the extent
of a target block or catch at the moment the values are returned, and
end the extent of a passed-over exit at the moment the THROW, RETURN, or
GO commences. This choice of extent maximizes efficiency within the
particular stack structure used by these implementations, by avoiding
the need to retain the control information needed to use a passed over
exit through the transfer of control. Genera signals an error if an
attempt is made to use an exit that has been passed over.
In some implementations, the extent of a target exit lasts until the
exit has been completed; in those implementations, it is possible for a
throw or non-local exit to be effectively "stopped" by an UNWIND-PROTECT
cleanup clause that performs a nonlocal transfer of control to a
passed-over exit.
Cost to Implementors:
No currently valid implementation will be made invalid by this proposal.
Some implementors may wish to add error checks if they do not already
have them.
Cost to Users:
Since this is a clarification and current implementations differ, this
issue ostensibly does not affect current portable programs.
Cost of non-adoption:
The semantics of exits will remain ambiguous.
Benefits:
Common Lisp will be more precisely defined, and the precise definition
will be consistent with current practice in a way that has no cost for
implementors nor for users.
Esthetics:
Precisely specifying the meaning of dynamic extent improves the language.
Leaving implementations free to implement a longer extent if they choose
can be regarded as unesthetic, but consistent with Common Lisp philosophy.
Having a CATCH that is in scope even though its extent has ended may
seem unesthetic, but it is consistent with how BLOCK behaves.
Discussion:
One aspect of this issue, namely the particular behavior of non-local
exits from unwind protect cleanup clauses, was discussed at great
length. Some of that discussion centered around the possibility of
creating "unstoppable loops" that could not be exited, by constructs
like
(tagbody retry (unwind-protect .... (go retry)))
The goal of this proposal is to clarify the ambiguity in CLtL while
minimizing changes to the current situation. An alternative proposal
would define the extent of an exit to end at the last moment possible
within some particular reference implementation. That alternative would
have a cost to implementors whose implementation is not identical to the
reference implementation. Another alternative proposal would duck the
issue by outlawing all nonlocal exits from UNWIND-PROTECT cleanup forms.
That alternative would have a substantial cost to some users.
Scheme is cleaner: it avoids this issue by specifying that the extent
of an exit never ends.
CLtL never says in what dynamic environment cleanup forms of
UNWIND-PROTECT are executed. The implementation note on p.142 may have
been intended to cover this, but since it doesn't define the term
"frame" that it uses, it doesn't actually say anything. The extent of
dynamic-extent entities other than exits should be the
subject of a separate proposal.
∂08-Oct-88 1651 X3J13-mailer Issue: EQUAL-STRUCTURE (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 16:50:46 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 16:33:06 PDT
Date: 8 Oct 88 16:33 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: EQUAL-STRUCTURE (Version 5)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-163306-2318@Xerox>
Our intent is to leave EQUAL and EQUALP alone. We are just having
difficulty saying what it does now.
We thought this deserved an "issue" even though it is status quo
because the issue arises frequently, and it was circulated for the
June 1988 X3J13 in a different form.
!
Issue: EQUAL-STRUCTURE
References: EQUAL (p80), EQUALP (p81)
Category: CLARIFICATION/CHANGE
Edit history: 18-Mar-88, Version 1 by Pitman
08-Jun-88, Version 2 by Masinter (add Benson's proposal)
23-Sep-88, Version 3 by Masinter (remove all but STATUS-QUO)
01-Oct-88, Version 4 by Masinter (fix description)
01-Oct-88, Version 5 by Pitman (correct wording, add discussion)
Problem Description:
The behavior of EQUAL and EQUALP on structures is a subject of controversy.
At issue are whether these functions should descend the slots of structures
or use simply the structure's primitive identity (i.e., EQ) to test for
equivalence.
Proposal (EQUAL-STRUCTURE:STATUS-QUO):
Clarify that EQUAL and EQUALP do not descend any structures or
data types other than the ones explicitly specified in CLtL.
EQUAL uses EQL for numbers and characters, descends structure for CONSes
bit-vectors, strings; has special behavior for pathnames as specified
in CLtL, and uses EQ for all other types.
EQUALP is similar, except that it ignores case in strings, and it
descends arrays, structures, and instances. It uses EQ for
all other types; for example, it does not descend hash tables.
Rationale:
There seem to be as many different equality primitives as there
are applications for them. None of the possible ways of changing
EQUAL or EQUALP are flawless. Given the inability to "fix" them,
it is better to leave them alone.
Current Practice:
We are unaware of any extensions to CLtL's set of operations,
although frequently users request them.
Cost to Implementors:
Since this seems to be compatible with the status quo, none.
Cost to Users:
Same
Cost of Non-Adoption:
Ongoing controversy about whether EQUAL and EQUALP "do the right thing".
Benefits:
A feeling that EQUAL and EQUALP exist and/or do what they do because serious
consideration was given and we consciously decided on a particular resolution
to the numerous questions that have come up about them.
Aesthetics:
There seems to be wide debate about what the proper aesthetics for
how equality should work in Common Lisp. While the status quo is not
aesthetically more pleasing than the various alternatives, aesthetic
considerations vary widely. Different people model structures
differently. Sometimes the same person models structures differently in
different situations. The question of which should be descended and which
should not is a very personal one, and the aesthetic attractiveness of any
of these options will vary from person to person or application to
application.
Discussion:
An earlier version of this issue with various alternatives was distributed
at the June 1988 X3J13 meeting. Since
this is a frequently raised issue, we thought we should submit it
as a clarification although there is no change to CLtL.
Options for which we considered proposals were:
- removing EQUAL and EQUALP from the standard.
- changing EQUALP to descend structures.
- changing EQUALP to be case sensitive.
- adding a :TEST keyword to EQUAL.
- making EQUAL a generic function
All of these had some serious problems.
The cleanup committee supports option STATUS-QUO.
It would be useful if descriptions of EQUAL and EQUALP contained some sort
of additional commentary alluding to the complex issues discussed here.
The following is offered to the Editorial staff as a starting point:
Object equality is not a concept for which there is a uniquely
determined correct algorithm. The appropriateness of an equality
predicate can be judged only in the context of the needs of some
particular program. Although these functions take any type of
argument and their names sound very generic, EQUAL and EQUALP are
not appropriate for every application. Any decision to use or not
use them should be determined by what they are documented to do
rather than any abstract characterization of their function. If
neither EQUAL nor EQUALP is found to be appropriate in a particular
situation, programmers are encouraged to create another operator
that is appropriate rather than blame EQUAL or EQUALP for ``doing
the wrong thing.''
∂08-Oct-88 1651 X3J13-mailer DRAFT Issue: DOTTED-MACRO-FORMS (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 16:50:41 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 16:15:32 PDT
Date: 8 Oct 88 16:15 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: DOTTED-MACRO-FORMS (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-161532-2307@Xerox>
The cleanup committee (and individual members of the committee)
have mixed opinions about this issue.
!
Issue: DOTTED-MACRO-FORMS
References: forms (p54), lists and dotted lists (pp26-27),
DEFMACRO (p145), destructuring macro arguments (p146)
Category: CLARIFICATION
Edit history: 28-Jun-88, Version 1 by Pitman
1-Oct-88, Version 2 by Masinter
Problem Description:
CLtL is not explicit about whether macro forms may be dotted lists.
p54 says that only certain forms are "meaningful": self-evaluating
forms, symbols, and "lists".
pp26-27 defines "list" and "dotted list". It goes on to say
``Throughout this manual, unless otherwise specified, it is an
error to pass a dotted list to a function that is specified
to require a list as an argument.''
p146 states that in DEFMACRO destructuring, ``the argument
form that would match the parameter is treated as a
(possibly dotted) list, to be used as an argument forms list
for satisfying the parameters in the embedded lambda list.''
It goes on to say that ". var" is treated like "&rest var"
at any level of the defmacro lambda-list.
Proposal (DOTTED-MACRO-FORMS:DISALLOW):
Specify that it is an error for a macro form to be a dotted list.
Rationale:
Dotted lists are a possible symptom of program syntax error.
Allowing implementations to check for this error may catch enough
errors to justify the loss of program flexibility.
Test Case:
#1: (DEFMACRO MACW (&WHOLE W &REST R) `(- ,(CDR W)))
(MACW . 1) => ??
#2: (DEFMACRO MACR (&REST R) `(- ,R))
(MACR . 1) => ??
#3: (DEFMACRO MACX (&WHOLE W) `(- ,(CDR W)))
(MACX . 1)
(MACW . 1) would be an error under this proposal.
(MACR . 1) would be an error under this proposal.
Current Practice:
A. Some implementations bind W to (MACW . 1) in #1 and #3
and bind R to 1 in #1 and #2.
B. Some implementations bind W to (MACW . 1) in #3
and signal a syntax error in #1 and #2.
C. Some implementations signal a syntax error in #1, #2, and #3.
Symbolics Genera is such an implementation.
Cost to Implementors:
As written, this proposal doesn't require implementations to check for
the error condition.
Cost to Users:
Some users depend on this behavior in current implementations, although
such use is not widespread.
Benefits:
People would know what to expect.
Aesthetics:
Mixed opinion; certainly it is better to specify whether they are allowed
or an error than to be vague. Some feel that disallowing dotted macro
forms makes the language cleaner.
Discussion:
Goldman@VAXA.ISI.EDU raised this issue on Common-Lisp.
This issue came up primarily in the context of program-written programs;
a macro used in the program generated code might occasionally use
a dotted tail to a list to explicitly represent special conditions.
Allowing dotted macro forms may blur the data/code distinction too much,
particularly for people who are new to Lisp.
Some people believe that there's no reason to unnecessarily restrict
&WHOLE and/or &REST since there is no computational overhead and since
the interpretation, if there is one at all, is pretty well agreed upon.
- - - - - - - - Additional Discussion - - - - - -
Allow them only with a declaration?
This is an issue of error-checking vs flexibility, we think.
There is a consistency argument: dotted arguments are definitely
disallowed in function argument lists, and almost certainly allowed
in embedded macro arguments; which should the top-level macro
argument lists be consistent with?
∂08-Oct-88 1703 X3J13-mailer DRAFT Issue: FORMAT-PRETTY-PRINT (version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:02:57 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 16:58:10 PDT
Date: 8 Oct 88 16:58 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: FORMAT-PRETTY-PRINT (version 5)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-165810-2344@Xerox>
The only comment on this issue is on the binding of *PRINT-BASE*
under ~E, ~R, e.g. (LET ((*PRINT-BASE* 8)) (FORMAT NIL "~R" 8))
or (LET ((*PRINT-BASE* 8)) (FORMAT NIL "~E" 8.5))
!
Status: DRAFT
Issue: FORMAT-PRETTY-PRINT
References: FORMAT (pp. 385-388), PRIN1 (p. 83), PRINC (p. 83),
WRITE (p. 382), *PRINT-PRETTY* (p. 371)
Category: CLARIFICATION
Edit history: Version 1 by Pierson 3/4/88
Version 2 by Pierson 5/24/88 (fix name typo)
Version 3 by Pierson 6/10/88 incorporate comments
Version 4 by Pierson 6/10/88 comments from Van Roggen
Version 5 by Masinter 2-Oct-88
Problem description:
The FORMAT operators, ~A and ~S are defined to print their argument as
PRINC and PRIN1 respectively. The text does not say whether or not
these FORMAT operators must obey the *PRINT-PRETTY* flag.
Proposal (FORMAT-PRETTY-PRINT:YES):
Specify that FORMAT does not rebind any of the printer control
variables (*PRINT-...) except as follows:
~A
Binds *PRINT-ESCAPE* to NIL.
~S
Binds *PRINT-ESCAPE* to T.
~D
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 10.
~B
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 2.
~O
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 8.
~X
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 16.
~R
Iff a first argument is specified, binds *PRINT-ESCAPE* to NIL,
*PRINT-RADIX* to NIL, and *PRINT-BASE* to the value of the first
argument.
~@C
Binds *PRINT-ESCAPE* to T.
~F,~G,~E,~$
Binds *PRINT-ESCAPE* to NIL.
Test Cases/Examples:
(LET ((TEST '#'(LAMBDA (X)
(LET ((*PRINT-PRETTY* T))
(PRINT X)
(FORMAT T "~%~S " X)
(TERPRI) (PRINC X) (PRINC " ")
(FORMAT T "~%~A " X)))))
(FUNCALL (EVAL TEST) TEST))
This should print four copies of the above lambda expression. The
first pair should appear identical and the second pair should appear
identical. The only difference between the two pairs should be the
absence of string quotes in the second pair.
<<the test is not accurate in systems where prettyprinting
might indent differently when *print-escape* is NIL.>>
Rationale:
FORMAT should interact with the printer control variables in a
predictable way. This proposal is one of the two simplest possible
definitions and provides the most flexibility to the user.
A major advantage of this proposal is that the following two
expressions are guaranteed to have exactly the same effect:
(FORMAT stream "~S" object)
(PRIN1 object stream)
Thus use or non-use of FORMAT becomes a purely stylistic matter.
Current practice:
Ibuki Lisp and the TI Explorer obey the binding of *PRINT-PRETTY*.
Lucid Common Lisp always applies ~A and ~S with *PRINT-PRETTY* bound
to NIL.
Cost to Implementors:
While changing FORMAT to not bind *PRINT-foo* variables is trivial,
there are some painful implications. How does a pretty-printing ~A
interact with MINCOL, etc? How much of the user interface depends on
FORMAT in ways that might be uglified by pretty printing?
Cost to Users:
Truely portable code shouldn't be affected because existing
implementations are inconsistent. Despite this, there are probably a
number of user programs in non-complying which will have to change
whichever way this is decided.
Cost of non-Adoption:
The interaction of FORMAT and the printer control variables (especially
*PRINT-PRETTY*) will remain undefined. This will continue to make
portable Common Lisp programming harder than it need be.
Benefits:
Life will be easier for users in two ways: (1) one more portability
problem will be removed, and (2) users will be more likely to be able
to persuade environmental features like debuggers to print in their
preferred way.
Aesthetics:
The interaction between two related parts of output will be clarified
in a simple way.
Discussion:
It is important to specify exactly what of Common Lisp's special
variables get rebound by other functions and macros in Common Lisp.
This cleanup issue addresses the interaction of FORMAT and the
*PRINT- variables. There may be other similar interactions in
Common Lisp that need clarification.
Otherwise, code that depends on FORMATs action in one implementation
will not port to others that do not have the same behavior.
CLtL might change as follows:
Add a header "Printer Control Variables" before the description of
*PRINT-ESCAPE* on page 370.
Add the following paragraph to page 386 just before the paragraph
starting with "It is an error":
"The FORMAT function by itself never binds any of the printer
control variables. Specific FORMAT directives bind exactly the
printer control variables specified in their description. While
implementations may specify the binding of new, implementation
specific printer control variables for each FORMAT directive, they
may neither bind any standard printer control variables not
specified in description of a FORMAT directive nor fail to bind
any standard printer control variables as specified in the
description."
∂08-Oct-88 1726 X3J13-mailer DRAFT Issue: FUNCTION-COERCE-TIME (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:26:25 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 17:10:18 PDT
Date: 8 Oct 88 17:10 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: FUNCTION-COERCE-TIME (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-171018-2362@Xerox>
This proposal has not yet been resolved in the cleanup committee.
There are a variety of options being considered, as you can tell.
!
Status: DRAFT
Issue: FUNCTION-COERCE-TIME
References: SET-MACRO-CHARACTER (p362),
SET-DISPATCH-MACRO-CHARACTER (p364),
MAP (p249), MAPL (p129), ...
Functions using :TEST, :KEY, etc. (REDUCE, MEMBER, DELETE, ...)
Functions using a positional predicate (SORT, DELETE-IF, ...)
Category: CLARIFICATION
Edit history: 20-Jun-88, Version 1 by Pitman
16-Sep-88, Version 2 by Pitman
(changes to presentation of all proposals per Masinter's comments)
Status: For Internal Discussion
Problem Description:
Many functions which accept arguments which are to be treated functionally
but which are not of type FUNCTION. This functionality can be very useful,
but the time at which the coercion is accomplished must be made clear.
Proposal (FUNCTION-COERCE-TIME:LAZY):
Specify that when a non-function (eg, a symbol) is used as a functional
argument to an operator, the coercion of that non-function to a function
is delayed until the function is about to be called and is done anew
every time the function is to be called. That is, passing a non-function
functional argument, F, is equivalent to passing
#'(LAMBDA (&REST ARGUMENTS)
(APPLY F ARGUMENTS))
Rationale:
One of the main reasons that it may be useful to pass a non-function
instead of a function is to accomplish indirection which allows later
redefinitions to take proper effect. Early binding would tend to
thwart the usefulness of such indirection and force people into
notationally more clumsy devices.
Proposal (FUNCTION-COERCE-TIME:AMBITIOUS):
Specify that when a non-function (eg, a symbol) is used as a functional
argument to an operator, the coercion of that non-function to a function
is done immediately. That is, all such functions treat a non-function
functional argument, F, as if
(COERCE F 'FUNCTION)
had been passed instead.
Rationale:
This is easier to implement since the coercion is done up front and
no further worry about uncoerced functions is needed internally.
Also, inlining of mapped functions (without using temporary storage
to hold a cached value of the function being mapped) can be done
without needing to know whether the function being inlined will
affect the place which holds the functional argument being passed.
Proposal (FUNCTION-COERCE-TIME:HYBRID):
Specify that when a non-function (eg, a symbol) is used as a
functional argument to an operator, the coercion of that non-function
to a function must be done immediately if the functional argument is
to be used only internally to the function (eg, SORT or MAPCAR).
Otherwise, if the functional argument's use persists beyond the end
of the call to the operator (eg, SET-MACRO-CHARACTER), any coercion is
delayed until the function is about to be called and is done anew every
time the function is to be called.
That is, functions like SORT and MAPCAR are permitted to treat a
non-function functional argument, F, as if
(COERCE F 'FUNCTION)
had been passed instead. However, functions like SET-MACRO-CHARACTER
would treat a non-function functional argument, F, as if
#'(LAMBDA (&REST ARGUMENTS)
(APPLY F ARGUMENTS))
were passed instead.
Rationale:
Debugging is enhanced for operations such as SET-MACRO-CHARACTER
without needlessly hampering useful optimizations to things like
SORT or MAPCAR, which very rarely require this facility.
Test Cases:
(DEFVAR *SOME-FUNCTIONS*
(LIST #'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 1)
#'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 2)
#'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 3)
#'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 4)))
; Control situation A
(PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
(LIST (MAPCAR #'(LAMBDA (&REST X) (APPLY #'FOO X))
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 2 3) 4)
; Control situation B
(LET ((FOO (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))))
(LIST (MAPCAR FOO
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 1 1) 4)
; Interesting Situation 1
(PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
(LIST (MAPCAR #'FOO
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 2 3) 4) ;Lazy-1
or ((1 1 1 1) 4) ;Ambitious-1
; Interesting Situation 2
(PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
(LIST (MAPCAR 'FOO
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 2 3) 4) ;Lazy-2
or ((1 1 1 1) 4) ;Ambitious-2
(DEFUN SHARP-DOLLAR (STREAM CHAR N)
(DECLARE (IGNORE CHAR))
(EXPT (READ STREAM) (OR N 1)))
(SET-DISPATCH-MACRO-CHARACTER #\# #\$ 'SHARP-DOLLAR)
(VALUES (READ-FROM-STRING "(#$3 #4$3)"))
=> (3 81)
(DEFUN SHARP-DOLLAR (STREAM CHAR N)
(DECLARE (IGNORE CHAR))
(+ (READ STREAM) (* (OR N 0) 0.01)))
(VALUES (READ-FROM-STRING "(#$3 #4$3)"))
=> (3.0 3.04) ;Lazy-3
(3 81) ;Ambitious-3
Proposal LAZY requires LAZY-1, LAZY-2, LAZY-3.
Proposal AMBITIOUS requires AMBITIOUS-1, AMBITIOUS-2, AMBITIOUS-3.
Proposal HYBRID requires AMBITIOUS-1, AMBITIOUS-2, LAZY-3.
Current Practice:
Implementations are permitted to differ in when they do the coercion since
the coercion time is not clearly spelled out.
(In the test case, LAZY-1 can occur only if MAPCAR is inlined, and then
only if the original value of the function definition is not cached.)
[Some info below is based on empirical testing -- I didn't look at the
source or try to see how speed/safety affect things. -kmp]
Symbolics Genera implements AMBITIOUS-1 interpreted and LAZY-1 compiled.
Symbolics Cloe (a compiled-only lisp) implements LAZY-1 both `interpreted'
and compiled.
Both Symbolics Genera and Symbolics Cloe implement LAZY-2.
Symbolics Genera implements LAZY-3.
Symbolics Cloe implements AMBITIOUS-3.
Cost to Implementors:
[Costs may vary widely depending on current practice.
I'll leave this one open for now pending feedback from others. -kmp]
Cost to Users:
This change is upward compatible.
Cost of Non-Adoption:
A very important aspect of the language would be left unspecified.
Portability would suffer.
Benefits:
HYBRID has the benefit of making things like readmacros easier to debug.
LAZY offers the additional benefit of being able to repair certain
functional arguments to SORT or MAPCAR (eg, as a symbol) in the debugger,
and then to proceed the error (in implementations offering that restart
option) in a way that makes the ongoing call to SORT or MAPCAR notice
the repairwork right away.
Aesthetics:
Since this is a visible aspect of the language, anything which clarified
the behavior that a programmer might expect would seem to improve the
aesthetics somewhat.
Discussion:
This issue was raised by Nick Gall and written up by Pitman.
Pitman supports FUNCTION-COERCE-TIME:HYBRID.
∂08-Oct-88 1726 X3J13-mailer DRAFT Issue: FUNCTION-COMPOSITION (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:26:34 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 17:20:36 PDT
Date: 8 Oct 88 17:20 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: FUNCTION-COMPOSITION (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-172036-2376@Xerox>
The comments on this issue so far deal with the possibility
of removing :TEST-NOT, and some minor problems with the
definition of COMPOSE. (E.g., (COMPOSE) might return
#'VALUES.)
However, comment on the main issue, whether this is important
enough to add to the language, is welcome.
!
Status: DRAFT
Issue: FUNCTION-COMPOSITION
References: None
Category: ADDITION
Edit history: 21-Jun-88, Version 1 by Pitman
05-Oct-88, Version 2 by Pitman
Related-Issues: TEST-NOT-IF-NOT
Problem Description:
A number of useful functions on functions are conspicuously
absent from Common Lisp's basic set. Among them are functions
which return constant T, constant NIL, and functions which
combine functions in common, interesting ways.
Proposal (FUNCTION-COMPOSITION:NEW-FUNCTIONS):
Add the following functions:
COMPOSE &REST functions [Function]
Returns a function whose value is the same as the composition
of the given functions. eg, (FUNCALL (COMPOSE #'F #'G #'H) A B C)
is the same as (F (G (H A B C))). Also, for example, #'CAADR may
be described as (COMPOSE #'CAR #'CAR #'CDR).
CONJOIN &REST functions [Function]
Returns a function whose value is the same as the AND of the
given functions applied to the same arguments.
DISJOIN &REST functions [Function]
Returns a function whose value is the same as the OR of the
given functions applied to the same arguments.
COMPLEMENT function [Function]
Returns a function whose value is the same as the NOT of the
given function applied to the same arguments.
ALWAYS value [Function]
Returns a function whose value is always VALUE.
Examples:
(MAPCAR #'(LAMBDA (X) (DECLARE (IGNORE X)) T) '(3 A 4.3))
==
(MAPCAR (ALWAYS T) '(3 A 4.3))
=> (T T T)
(MAPCAR #'(LAMBDA (X) (AND (NUMBERP X) (ZEROP X))) '(3 A 0.0))
==
(MAPCAR (CONJOIN #'NUMBERP #'ZEROP) '(3 A 0.0))
=> (NIL NIL T)
(FIND-IF #'(LAMBDA (X) (AND (INTEGERP X) (SYMBOLP X))) '(3.0 A 4))
==
(FIND-IF (DISJOIN #'INTEGERP #'SYMBOLP) '(3.0 A 4))
=> A
(FUNCALL #'(LAMBDA (&REST X) (REVERSE (APPLY #'LIST* X))) 3 4 5 '(6 7))
==
(FUNCALL (COMPOSE #'REVERSE #'LIST*) 3 4 5 '(6 7))
=> (7 6 5 4 3)
(FIND-IF-NOT #'ZEROP '(0 0 3))
==
(FIND-IF (COMPLEMENT #'ZEROP) '(0 0 3))
=> 3
Rationale:
The presence of these functions will contribute to syntactic
conciseness in some cases, and more importantly will permit
a programming style which is currently discouraged by most
Common Lisp implementations.
It is technically possible to define this functionality portably,
the really important part of this proposal is that native compiler
support is needed to really do them justice. Portable implementations
are not likely to be efficient enough for serious use.
Placing these functions in the core language not only permits
but encourages a very useful set of compiler optimizations that
would otherwise be difficult to obtain.
In principle, a proposal to flush the :TEST-NOT keywords and the
-IF-NOT functions could even be entertained if the COMPLEMENT
function were added. [See issue TEST-NOT-IF-NOT.]
Current Practice:
No Common Lisp implementations provide these primitives, but they do
exist in the T language.
Cost to Implementors:
A straightforward implementation is simple to cook up. The definitions
given here would suffice. Typically some additional work might be
desirable to make these open code in interesting ways.
(DEFUN COMPOSE (&REST FUNCTIONS)
(COND ((NOT FUNCTIONS)
(ERROR "COMPOSE requires at least one function."))
((NOT (REST FUNCTIONS))
(FIRST FUNCTIONS))
(T
(LET ((REVERSED-FUNCTIONS (REVERSE FUNCTIONS)))
(LET ((LAST-FUNCTION (FIRST REVERSED-FUNCTIONS))
(OTHER-FUNCTIONS (REST REVERSED-FUNCTIONS)))
#'(LAMBDA (&REST ARGUMENTS)
(DO ((O OTHER-FUNCTIONS (CDR O))
(VAL (APPLY LAST-FUNCTION ARGUMENTS)
(FUNCALL (CAR O) VAL)))
((NULL O) VAL))))))))
(DEFUN CONJOIN (&REST FUNCTIONS)
#'(LAMBDA (&REST ARGUMENTS)
(DO ((F FUNCTIONS (CDR F))
(VAL T (AND VAL (APPLY (CAR F) ARGUMENTS))))
((OR (NULL VAL) (NULL F)) VAL))))
(DEFUN DISJOIN (&REST FUNCTIONS)
#'(LAMBDA (&REST ARGUMENTS)
(DO ((F FUNCTIONS (CDR F))
(VAL NIL (OR VAL (APPLY (CAR F) ARGUMENTS))))
((OR VAL (NULL F)) VAL))))
(DEFUN COMPLEMENT (FUNCTION)
#'(LAMBDA (&REST ARGUMENTS)
(NOT (APPLY FUNCTION ARGUMENTS))))
(DEFUN ALWAYS (VALUE)
#'(LAMBDA (&REST ARGUMENTS)
(DECLARE (IGNORE ARGUMENTS))
VALUE))
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
(COMPLEMENT BENEFITS)
Benefits:
Some code would be more clear.
Some compilers might be able to produce better code.
Takes a step toward being able to flush the -IF-NOT functions
and the :TEST-NOT keywords, both of which are high on the list
of what people are referring to when they say Common Lisp is
bloated by too much garbage.
Aesthetics:
In situations where these could be used straightforwardly, the
alternatives are far less perspicuous.
Discussion:
Pitman and van Roggen support the proposal.
Jim McDonald (JLM@Lucid.COM) seemed supportive of this proposal
and even suggested adding more elaborate operators such as
PERMUTE and COMMUTE. eg, (COMMUTE #'CONS) would be like what
Maclisp called XCONS.
Masinter wavered on this issue, but currently seems to support it.
Fahlman thinks this slightly gratuitous but is not opposed to
it if others think it is a good idea.
∂08-Oct-88 1741 X3J13-mailer DRAFT Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:41:14 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 88 17:30:01 PDT
Date: 8 Oct 88 17:30 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-173001-2379@Xerox>
!
Status: DRAFT -- several issues raised not addressed here
Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
References: CLtL pp 47-48, 158-159
Category: CHANGE
Edit history: #1, 7 Sept 1988, Walter van Roggen
#2, 13 Sept 1988, Walter van Roggen (costs & proposal limitations)
Problem description:
The current description of the specialized FUNCTION type specifier is not very
useful to program analysis tools and is not very intuitive to programmers
because the meaning of the argument type specifiers is not restrictive.
Programmers find it useful to add information about the types of the arguments
a function expects and about the type(s) that a function may return. This
information is useful both to human readers of the code as well as to type
checking programs such as compilers and cross referencers. The only apparent
(but false) way of providing this information is with the FTYPE declaration and
FUNCTION type specifier.
Furthermore, implementations may wish to provide additional optimizations based
on avoiding type checking or different methods of argument passing. These
optimizations require the same sort of information about the argument types.
However, the current definition of FUNCTION type specifiers on pages 47-48 of
CLtL states that a function such as CONS that is of type
(FUNCTION (T T) CONS)
is also of type
(FUNCTION (FLOAT STRING) LIST).
Unfortunately this information is not useful for the above mentioned purposes.
The problem is that the argument types aren't restrictive, so no interesting
matching of types is possible.
Another way of looking at the problem is that specialized FUNCTION type
specifiers cannot be used in a meaningful way for discrimination (as the second
arg to TYPEP, nor as the first argument to THE). Furthermore functions are
assumed not to be sufficiently self-descriptive that a specialized FUNCTION
type is possible to be known or can be constructed when a function is passed to
TYPE-OF.
Thus unlike all the other type declarations, which can be used for
discrimination and have an implicit effect on representation, specialized
FUNCTION type specifiers appear to have superfluous information. By changing
the meaning of the argument types to convey additional descriptive information
instead of behavioral information, we can also satisfy the other needs listed
above.
Proposal (FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE)
For specialized FUNCTION type specifiers
(proclaim '(ftype (function (arg0-type arg1-type ...) val-type) f))
implies
(the val-type (f (the arg0-type ...) (the arg1-type ...) ...))
If the arguments to F are of the specified types, then the result will be of
the specified type. If the arguments do not all match the specified types, it
is an error, and then the result is not guaranteed to be of the specified type.
This proposal does not alter the status (or lack thereof) of other issues
related to FUNCTION type specifiers: what lambda-list keywords mean, what the
VALUES type means, what implications there are w.r.t. argument counts, doing
multiple PROCLAIMs, doing local DECLAREs that shadow other declarations or
proclamations, describing generic functions incrementally, the result of TYPEP
with a specialized FUNCTION type.
Rationale:
The proposal seems most like what users expect.
Current Practice:
VAX LISP already assumes and makes use of the "restrictive" semantics. Lucid
has a RESTRICTIVE-FTYPE declaration with these semantics and ignores the
standard FTYPE declaration. Gold Hill intends to use these declarations in this
manner. Many implementations don't make use of these declarations. At least
several users make use of declarations assuming the new semantics.
Cost to Implementors:
Since most implementations don't make use of function declarations, and since
those known to do so can be changed easily, the cost should be minimal.
Cost to Users:
There may be some existing "imprecise" function declarations. However, the
natural tendency when providing these declarations is to be as "descriptive"
(i.e., restrictive but complete) as possible, both for documentation purposes
as well as for potential compiler benefits. There cannot have been any uses of
the specialized FUNCTION type for discrimination. Thus most existing uses are
probably compatible with this new definition.
Cost of Non-Adoption:
There already exists user code on many implementations that assume the
proposed semantics. Not adopting this proposal would continue to render
such code incorrect or at least non-portable.
Benefits:
Better type checking and more compiler optimizations should be possible.
Esthetics:
This is the what most programmers expect the specialized FUNCTION type to
mean, particularly those coming from other languages.
Discussion:
Is it the case that this proposal makes no statement on the issue of
what happens if you do multiple proclamations for the same function?
I don't think you can completely ignore the issue because
(FUNCTION (FIXNUM FIXNUM) CONS)
is a proper global declaration for CONS if multiple declarations are
permitted, but not if only one declaration is permitted.
I think that much of the confusion about function type declarations is
because there are two aspects of the issue that have not been clearly
delimited:
1. Declarations describing the definition of a function.
2. Declarations about functions expected to be received by an argument
or variable.
The proposal FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE addresses
the first case, while the discussion in CLtL seems to have primarily the
second case in mind.
- - - - -
The function type constructor is anti-
monotonic in its first argument, unlike most other other type constructors
which are monotonic in all arguments. That is,
If X is a subtype of Y
then Z --> X is a subtype of Z --> Y
but Y --> Z is a subtype of X --> Z.
It would be good if Common Lisp's notion of "type" and "subtype" could
be made consistent with this fact.
∂08-Oct-88 1741 X3J13-mailer DRAFT Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:41:35 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 17:38:18 PDT
Date: 8 Oct 88 17:38 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-173818-2382@Xerox>
!
Issue: HASH-TABLE-PACKAGE-GENERATORS
References:
Category: ADDITION
Edit history: Version 1, 23-May-88 JonL
Version 2, 6-Oct-88 JonL (convert to "with" scoping).
Version 3, 7-Oct-88 JonL (mly's syntax for package iterator)
Problem description:
The Iteration subcommittee would like the several iteration proposals to be
writeable in portable Common Lisp code. Unfortunately, the only complete
access to hash-tables and packages is through MAPHASH and DO-SYMBOLS (and
DO-EXTERNAL-SYMBOLS and DO-ALL-SYMBOLS); none of these existing primitives
is satisfactory for building complex iteration clauses.
Proposal (HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER)
Add two new macros WITH-HASH-TABLE-ITERATOR and WITH-PACKAGE-ITERATOR
to the language as follows:
WITH-HASH-TABLE-ITERATOR ((<next-fn> <hash-table>) &body body) [Macro]
Within the lexical scope of 'body', the name <next-fn> is defined
via MACROLET such that successive invocations of (<next-fn>) will
return the items, one by one, from the hash-table which is obtained
by evaluating <hash-table> [only once].
An invocation (<next-fn>) returns three values as follows:
;; 1. a boolean indicating whether an entry is returned (T says yes)
;; 2. the key item (of a <key, value> pair)
;; 3. the value item (of a <key, value> pair)
;; After all entries have been returned [by successive invocations of
;; (<next-fn>)], then only one value is returned, namely NIL.
WITH-PACKAGE-ITERATOR ((<next-fn> <package> [Macro]
&key external internal inherited)
&body body)
Within the lexical scope of 'body', the name <next-fn> is defined
via MACROLET such that successive invocations of (<next-fn>) will
return the items, one by one, from the package which is obtained
by evaluating <package> [only once].
An invocation (<next-fn>) returns three values as follows:
;; 1. a boolean indicating whether an entry is returned (T says yes)
;; 2. a symbol (available in the indicated package)
;; 3. the availability type for that symbol; i.e. one of
;; :INTERNAL, :EXTERNAL, or :INHERITED, or unspecified for
;; the DO-ALL-SYMBOLS case.
;; After all entries have been returned [by successive invocations of
;; (<next-fn>)], then only one value is returned, namely NIL.
The keyword arguments are flags indicating which kinds of symbols are
wanted; they are not "evaluated". The following combinations are
recognized:
+----------+----------+-------------+--------------------------------------
| external | internal | inherited | CLtL macro equivalent
+----------+----------+-------------+-------------------------------------
| T | T | T | DO-SYMBOLS
| T | T | NIL | DO-PRESENT-SYMBOLS [not CLtL]
| T | NIL | T | <none> [unspecified]
| T | NIL | NIL | DO-EXTERNAL-SYMBOLS
| NIL | T | T | <none> [unspecified]
| NIL | T | NIL | DO-INTERNAL-SYMBOLS [not CLtL]
| NIL | NIL | T | DO-INHERITED-SYMBOLS [not CLtL]
| NIL | NIL | NIL | DO-ALL-SYMBOLS
+----------+----------+-------------+--------------------------------------
In the default case, equivalent to DO-ALL-SYMBOLS, the value of the
<package> argument is ignored. The lines marked "[not CLtL]" mention
package iterator macros found in some implementations of Common Lisp;
their meaning should be self-explanatory. The lines marked "unspecified"
may be extended by an implementation to have the implied meaning.
In accord with common practice, the options that include "inherited"
symbols, and the DO-ALL-SYMBOLS option, are allowed to present the
same symbol multiple times. This is because a symbol may be "inherited"
from several different used packages; and a symbol may be present in
several different packages (in the DO-ALL-SYMBOLS case).
It is unspecified what happens if any of the implicit interior state
of an iteration is returned outside the dynamic extent of the WITH-...
form (such as by returning some closure over the invocation form).
Test-case:
The following function should return T on any hash-table, and signal
an error if the usage of 'with-hash-table-iterator' doesn't agree
with the corresponding usage of 'maphash'.
(defun test-hash-table-iterator (hash-table)
(let ((all-entries '())
(generated-entries '())
(unique (list nil)))
(maphash #'(lambda (key value) (push (list key value) all-entries))
hash-table)
(with-hash-table-iterator (generator-fn hash-table)
(loop
;;Note -- this is the "trivial" LOOP of CLtL p121
(multiple-value-bind (more? key value) (generator-fn)
(unless more? (return))
(unless (eql value (gethash key hash-table unique))
(error "Key ~S not found for value ~S" key value))
(push (list key value) generated-entries))))
(unless (= (length all-entries)
(length generated-entries)
(length (union all-entries generated-entries :test #'equal)))
(error "Generated entries and Maphash entries don't correspond"))
t))
The following function should return T on any package, and signal
an error if the usage of 'with-package-iterator' doesn't agree
with the corresponding usage of 'do-symbols'.
(defun test-package-iterator (package)
(unless (packagep package)
(setq package (find-package package)))
(let ((all-entries '())
(generated-entries '()))
(do-symbols (x package)
(multiple-value-bind (symbol accessibility)
(find-symbol (symbol-name x) package)
(push (list symbol accessibility) all-entries)))
(with-package-iterator (generator-fn package
:internal t :external t :inherited t)
(loop
;;Note -- this is the "trivial" LOOP of CLtL p121
(multiple-value-bind (more? symbol accessibility) (generator-fn)
(unless more? (return))
(let ((l (multiple-value-list (find-symbol (symbol-name symbol)
package))))
(unless (equal l (list symbol accessibility))
(error "Symbol ~S not found as ~S in package ~A [~S]"
symbol accessibility (package-name package) l))
(push l generated-entries)))))
(unless (and (subsetp all-entries generated-entries :test #'equal)
(subsetp generated-entries all-entries :test #'equal))
(error "Generated entries and Do-Symbols entries don't correspond"))
t))
The following functions prints out every interned symbol:
(defun print-all-symbols ()
(with-package-iterator (next-symbol nil)
(print (next-symbol))))
Rationale:
The particular way in which hash-tables and packages are represented
need not be standardized, or even exposed to the user. Yet a simpler
handle on them is needed for the various iteration paradigms to be written
in portable code. In fact, after these iterator macros are put into an
implementation, then MAPHASH and DO-<mumble>-SYMBOLS are trivial usages
of them; but no _efficient_ use of the current primitives will provide
the effect of the new macros, namely a form that _returns_ the elements
of a table "one by one".
Current Practice:
Nobody does it this way, but both Symbolics and Lucid are not far off.
Cost to Implementors:
Moderate. Possibly a couple day's to a week's work for an implementation
that has to start completely afresh. Something like this is already being
done by the standard package macros [CLtL, p187].
Cost to Users:
None.
Benefits:
Will provide a more basic primitive for iterating over hash-tables and
packages; will permit new iteration paradigms to be written in portable code.
Aesthetics:
All other things being equal, it is better to have more general primitives
than less general ones.
Discussion:
The Iteration Subcommittee supports this proposal (or, "used to" --
JonL 6-Oct-88).
One must be careful not to assume that the invocation (<next-fn>) is a
"generator" function call -- since <next-fn> is MACROLET'd in an
implementation dependent way, it could even turn into a special form like
(if something
(values nil)
(yet-another-function-call))
The scoping called for herein may not be quite so useful to the "generators"
style proposals; in particular they offer an interface wherein one may
create a "generator" function of indefinite extent that returns, one-by-one,
the elements of the table. The constrained scoping implicit in these
WITH-... macros is not so much for any kind of optimization, but rather
for coordination of such hash-table "locking" as may occur in multi-
processing implementations like Symbolics. Nevertheless, Dick Waters
thinks these macros should be put in anyway, since it clearly is a
requirement for a portable LOOP, and can be use in a limited context
(i.e., not "indefinite scope") for portable versions of ITERATE and OSS.
Of course, if an implementation _can_ support an indefinite extent for
a "generator" object returned out of the iterator forms, it is allowed
to do so by this proposal.
∂08-Oct-88 1741 X3J13-mailer DRAFTIssue: HASH-TABLE-ACCESS (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:41:26 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 88 17:35:50 PDT
Date: 8 Oct 88 17:35 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFTIssue: HASH-TABLE-ACCESS (version 1)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-173550-2380@Xerox>
!
Status: DRAFT -- see comments at end
Issue: HASH-TABLE-ACCESS
References: hash-tables (Chapter 21 of CLtL)
Category: ADDITION
Edit History: 13-Sept-88, version 1 by Walter van Roggen
Problem Description:
There are many characteristics of hash-tables which are specified upon
creation but are not accessible afterwards.
Proposal: (HASH-TABLE-ACCESS:PROVIDE)
Add the following functions to the language:
HASH-TABLE-REHASH-SIZE hash-table
Returns the current rehash size of a hash table.
HASH-TABLE-REHASH-THRESHOLD hash-table
Returns the current rehash threshold of a hash table.
HASH-TABLE-SIZE hash-table
Returns the current size of a hash table.
HASH-TABLE-TEST hash-table
Returns the test used for comparing keys in the hash table.
By default the value will be EQL.
Current Practice:
VAX LISP implements the proposal.
Cost to Implementors:
Most of these should be trivial to implement, since the information
must be present for nearly all types.
Cost to Users:
None. This is an upward-compatible extension.
Cost of Non-Adoption:
The benefits would not be available in a portable fashion.
Benefits:
Programs would be able to access useful information otherwise hidden.
For example, it would allow programs to gain statistics about hash
table usage that might enable better tuning.
Discussion:
None of these are required to be SETF'able, though that might be
a reasonable implementation-dependent extension.
This first appeared in ">GLS>clarifications.text" of 12/06/85.
- - - - -
Is it reasonable for implementations to extend the set of SETF-able forms? It
would seem to lead to more subtle incompatibilities, because there would be no
simple lexical analysis that would determine the use of an extension vs the
standard. Further, I don't think that HASH-TABLE-SIZE HASH-TABLE-TEST, are
reasonably SETF-able. If you change the :TEST, would would you do about entries
that now collide?
It would make more sense to make HASH-TABLE-REHASH-SIZE
HASH-TABLE-REHASH-THRESHOLD
both SETFable if it is reasonable to expect to do so.
I wonder before we add more slots for built in data structures if
we wouldn't be doing better if we made access to these via CLOS? I won't push on
that too hard....
- - - - -
this issue is one of the very clear "Clarifications" that Guy
Steele issued on 6-Dec-1985, and which have not hitherto been turned
into format "Cleanup" proposals.
For the "Current Practice" section, you can mention that ever since the
2.0 release Lucid has provided all four accessors, as well as setf methods
for HASH-TABLE-REHASH-THRESHOLD and HASH-TABLE-REHASH-SIZE. [However,
they have not been in Lucid's documentation until the 3.0 release].
Could you be convinced to ask the for two setf "methods" too?
One other request: the return value of HASH-TABLE-TEST should
be among the values of 'EQ, 'EQL, or 'EQUAL -- not among #'EQ,
#'EQL, or #'EQUAL.
∂08-Oct-88 1741 X3J13-mailer DRAFT Issue: FUNCTION-DEFINITION (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:41:01 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 88 17:25:54 PDT
Date: 8 Oct 88 17:25 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: FUNCTION-DEFINITION (Version 1)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-172554-2377@Xerox>
This issue is still actively being developed, as you can see.
This is just some evidence that we're working on it.
!
Status: DRAFT
Issue: FUNCTION-DEFINITION
References: none
Category: ADDITION
Edit history: 23-Jun-88, Version 1 by Pitman
Problem Description:
There are portable ways to turn symbols and lists into functions,
but there are no portable ways to get back the original symbols and
lists given the functions.
Proposal (FUNCTION-DEFINITION:OPTIONAL):
Introduce a new function called FUNCTION-DEFINITION which took as
its argument a function and returned three values:
#1: its ``definition'' as a symbol or list, or NIL if the
information was no longer available.
#2: NIL if the definition was enclosed in the null lexical
environment and something non-NIL if the definition was (or
might have been) enclosed in some non-null lexical environment.
[It is always safe for an implementation to return T for this
value.]
#3: the `name' of this function. the name is intended for debugging
only and may be any lisp object -- not necessarily one that would
be valid for use as a name in DEFUN or FUNCTION, for example.
By convention, NIL is used to mean that the function had no name.
Implementations would be free to not record this information, or to provide
primitives for flushing some or all of the information at any time.
Examples:
The following examples illustrate some possible return values, but
are not not intended to be exhaustive:
#1: (FUNCTION-DEFINITION #'(LAMBDA (X) X))
or (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), NIL, NIL
#2: (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) NIL), T, NIL
but -not- (LAMBDA (X) X), NIL, NIL
#3: (DEFUN FOO (X) X)
(SETF (SYMBOL-FUNCTION #'BAR) #'FOO)
(DEFUN FOO (Y) Y)
(FUNCTION-DEFINITION #'BAR)
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), T, FOO
#4: (DEFUN FOO ()
(FLET ((BAR (X) X))
#'BAR))
(FUNCTION-DEFINITION (FOO))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), T, (:INTERNAL FOO 0 BAR)
or (LAMBDA (X) X), T, "BAR in FOO"
Rationale:
This functionality would be useful to the pretty printer, debugger,
inspector, and other tools.
Cost to Implementors:
Because NIL can be returned as a first value, the amount of work forced
by this proposal is trivial. The following implementation is technically
legitimate, although many implementations would want to provide something
more useful:
(DEFUN FUNCTION-DEFINITION (FUNCTION)
(CHECK-TYPE FUNCTION FUNCTION)
(VALUES NIL NIL NIL))
Proposal (FUNCTION-DEFINITION:REQUIRED):
Introduce a new function called FUNCTION-DEFINITION which took as
its argument a function and returned three values:
#1: its ``definition'' as a symbol or list, or NIL if the
information was no longer available.
#2: NIL if the definition was enclosed in the null lexical
environment and something non-NIL if the definition was (or
might have been) enclosed in some non-null lexical environment.
[It is always safe for an implementation to return T for this
value.]
#3: the `name' of this function. the name is intended for debugging
only and may be any lisp object -- not necessarily one that would
be valid for use as a name in DEFUN or FUNCTION, for example.
By convention, NIL is used to mean that the function had no name.
Implementations would be free to not record this information in file
compilations. In-core calls to EVAL and COMPILE would be required to
retain the information, however.
Examples:
The following examples illustrate some possible return values, but
are not not intended to be exhaustive:
#1: (FUNCTION-DEFINITION #'(LAMBDA (X) X))
or (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), NIL, NIL
in compiled code.
(FUNCTION-DEFINITION (EVAL '(LAMBDA (X) X)))
would not be permitted to return NIL, NIL, NIL since the compilation
occurred in the same environment.
#2: (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) NIL), T, NIL
but -not- (LAMBDA (X) X), NIL, NIL
in compiled code.
(FUNCTION-DEFINITION (FUNCALL (EVAL '(LAMBDA () #'(LAMBDA (X) X)))))
would not be permitted to return NIL, NIL, NIL since the compilation
occurred in the same environment.
#3: (DEFUN FOO (X) X)
(SETF (SYMBOL-FUNCTION #'BAR) #'FOO)
(DEFUN FOO (Y) Y)
(FUNCTION-DEFINITION #'BAR)
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), T, FOO
in compiled code.
If the DEFUN had been done interactively, the call to
FUNCTION-DEFINITION would not be permitted to return NIL, NIL, NIL
since the compilation occurred in the same environment.
#4: (DEFUN FOO ()
(FLET ((BAR (X) X))
#'BAR))
(FUNCTION-DEFINITION (FOO))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), T, (:INTERNAL FOO 0 BAR)
or (LAMBDA (X) X), T, "BAR in FOO"
in compiled code.
If the DEFUN had been done interactively, the call to
FUNCTION-DEFINITION would not be permitted to return NIL, NIL, NIL
since the compilation occurred in the same environment.
Rationale:
This functionality would be useful to the pretty printer, debugger,
inspector, and other tools.
Additionally, this would be useful to programs which need to pass
around both a function and a representation of a function because a
single object could be passed which was efficient to call without
compromising the ability to reliably retrieve its representation.
Cost to Implementors:
Because NIL can be returned as a first value, the amount of work forced
by this proposal is small, but not trivial. A simple implementation
might allocate a slot in each function that could hold the definition,
or might allocate a hash table to hold the information.
Current Practice:
Many implementations record this information, but not all that do
publish an interface to extracting the information.
The language T has this operation and calls it DISCLOSE. It is the
conceptual inverse of the ENCLOSE which occurs in some Scheme dialects,
and is implemented as what CLOS would call a "generic function".
Cost to Users:
None. The change is upward compatible.
Cost of Non-Adoption:
Certain kinds of portable debugging tools would be harder to write.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
The phrase ``program is data; data is program'' comes up a lot in discussions
about Lisp. This makes the case for ``program is data'' more interesting.
Discussion:
Pitman would prefer FUNCTION-DEFINITION:REQUIRED if people would agree to it
because it is considerably more useful in practice, but would like to see at
least FUNCTION-DEFINITION:OPTIONAL.
- - - - - Additional comments - - - - - -
re: Now that we've supposedly finished with function-type,
is anybody working on a proposal to introduce a func-
tion that would retrieve the lambda-expression defini-
tion from a user-defined function object?
Lucid Common Lisp has such a function, called SOURCE-CODE. It retrieves
the lambda expression used in an interpretive definition, even after sub-
sequent compilation of the function; but it does not attempt to maintain
an "out-of-core" database like the emacs TAGS facility.
If there were to be such a function, what would be a
good name for it?
How about EXTRACT-LAMBDA-EXPRESSION ?
The T language provides such a primitive. It is called DISCLOSE
(named for symmetry with the ENCLOSE primitive which occurs in some
Scheme dialects and coerces a lambda expression into a procedure).
DISCLOSE may be overly generic-sounding for CL use, but I recommend
DISCLOSE-DEFINITION.
I assume that the proposal will allow this function to return NIL if
the original lambda expression has been compiled or optimized to the
point where it can no longer be retrieved? I wouldn't want to require
memory-tight implementations to keep around the original form in all
cases.
Since some applications for DISCLOSE have semantic impact, I don't agree
that it should be possible for an implementation to simply throw away
the information. I believe that we should spell out particular cases
in which it is or is not permissible. My personal preferences follow:
- No compiler should be required to retain the source code
when using the file compiler. That is, using COMPILE-FILE
does not make the definition available in the environment into
which the definitions are subsequently LOADed.
- I am agnostic about interactive DEFUN, etc. I am content to see
this information retained only at the discretion of the
interpreter.
- I would prefer that arguments to COMPILE be retained, and possibly
defuns done by explicit EVAL as well. The reason for this is that
programs like Macsyma which have need of this function do not just
go around peeking into arbitrary functions (in my experience). They
usually want to peek into functions that they themselves instantiated.
So primitives that allow explicit runtime instantiation of functions
on a case-by-case basis should be reliably invertible (in my opinion).
Notes:
- I would be ammenable to permitting this function to be SETF-able,
so that people could ``NIL out'' definitions they didn't want to
retain.
- I would also be ammenable to having a special argument to COMPILE
saying that the information must be retained. I don't care what
the default value was.
- If there is not any reliable situation in which a definition will
have this information retained, then all the uses I have ever had
for this except for pretty printing are nullified. Perhaps the
pretty printing argument is reason enough to have it, though.
- There is some question about whether in the case of named objects,
(DEFUN FOO (X) X)
(DISCLOSE-DEFINITION #'FOO) => (LAMBDA (X) X) or (DEFUN FOO (X) X)?
I think the latter.
Does whether FOO is still fdefined matter? I think not.
- - - - - -
After re-reading this for 30 seconds, I'd favor OPTIONAL.
(Well, maybe I actually can't tell the difference between OPTIONAL and
REQUIRED, and "OPTIONAL" sounds better to me. Maybe I'm someone who votes
for a candidate because of his accent.)
I'm a little uneasy about "-DEFINITION", because in the residential
environment biz, the "definition" is the entire DEFUN form, and not just
the lambda expression.
Is there another postfix you'd also feel comfortable with? You say Many
implementations record this information, but not all that do publish an
interface to extracting the information.
This issue should reference FUNCTION-TYPE as as part of the Problem
Statement say that this is something that people used to do with just plain
old lambda expressions, since after (DEFUN FOO (X) ...) that
(SYMBOL-FUNCTION 'FOO) would frequently return the lambda expression
directly.
Now, with KCL and HP Common Lisp, the expression you get may not match what
you put in, e.g., might have gone thru some kind of preprocessing. (I
think.)
Also, how can the "definition" be a symbol? In CommonLisp?
Didn't we go thru (SETF (SYMBOL-FUNCTION X) 'FROB) before?
∂08-Oct-88 1751 X3J13-mailer DRAFT Issue: HASH-TABLE-PRINTED-PREPRESENTATION (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:51:32 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 17:44:14 PDT
Date: 8 Oct 88 17:43 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: HASH-TABLE-PRINTED-PREPRESENTATION (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-174414-2396@Xerox>
The issues listed under Additional Comments still have not been resolved.
!
Status: DRAFT (see Additional Comments)
Issue: HASH-TABLE-PRINTED-PREPRESENTATION
Category: ENHANCEMENT
Edit history: 23-May-88, Version 1 by Touretzky
8-Jun-88, Version 2 by Masinter (as per cl-cleanup discussion)
Description:
Hash tables are currently second-class data structures when compared to
lists, vectors, and structures, because they have no READable printed
representation. This proposal introduces a #H reader syntax for hash
tables and a switch to control when hash tables will be printed this way.
Proposal (HASH-TABLES-PRINTED-REPRESENTATION:#H-NOTATION) :
1) Introduce the following reader notation for hash tables:
#nH(type (k1 v1) (k2 v2) ...)
"n" is the size of the table; it is analagous to the :size argument to
MAKE-HASH-TABLE. If omitted, the system picks some reasonable size.
"type" is one of EQ, EQL, or EQUAL. If omitted it defaults to EQL.
The (ki vi) pairs consist of a key and a value. There may be any number of
such pairs, including zero. Order is not significant. It is an error for
two keys to be identical (using the EQ, EQL, or EQUAL test, as
appropriate.)
2) Introduce a switch called *PRINT-HASH* whose initial value is
implementation-dependent. If *PRINT-HASH* is T, hash tables are printed
using the #H syntax (with all optional components supplied), subject to the
usual limits imposed by *PRINT-LEVEL* and *PRINT-LENGTH*. If *PRINT-HASH*
is NIL, hash tables are printed using the current #<HASH-TABLE ...> syntax.
Rationale:
This is a useful upward compatible extension (except in
implementations that have usurped #H for other purposes), with very
low adoption cost.
Cost to Implementors:
A simple change to PRIN1 and the pretty printer. Most of the code
will be similar to existing routines for printing vectors in #()
notation and arrays in #nA() notation. The reader would change to
read this notation.
Cost to Users:
Small. Programs that want to control all *PRINT- parameters will need
to know about yet another parameter.
Benefits:
This proposal makes hash tables first class objects. If
*PRINT-HASH* is T, their contents become visible in all the normal ways,
e.g., if FOO is bound to a hash table object, then typing FOO to a
read-eval-print loop will display the contents of the hash table. Hash
table contents may also be displayed by TRACE if the table is passed as an
argument; they may also be displayed by the debugger. Finally, hash tables
may be appear as literal objects in programs and be read or written to files.
Current practice:
We know of no current implementations of this proposal.
Although some implementations allow the user to see hash table contents
with DESCRIBE or INSPECT, not all do. CMU Common Lisp's DESCRIBE, for
example, does not show hash table contents. This reinforces the need for
a standard #H notation to guarantee that users can manipulate a hash table
as easily as a vector, array, or structure.
Discussion:
Several alternatives have been suggested for the syntax of #H.
- preferred notation: #H(EQL (FOO 37) (BAR 42))
- dotted pair notation: #H(EQL (FOO . 37) (BAR . 42))
- property list: #H(EQL FOO 37 BAR 42)
- pseudo-structure: #S(HASH-TABLE TYPE EQL SIZE 20 INITIAL-CONTENTS ((FOO 37) (BAR 42)))
One problem with the currently proposed #H notation is that it provides no
way to specify a rehash-size or rehash-threshold. This should not be a
fatal flaw, though. The #() notation is also incomplete: it cannot
indicate whether the vector has a fill pointer, nor can it show when the
element-type is something more specific than T. The latter problem is also
shared by #nA notation. Some object that the fact that #A is flawed is no
reason to introduce the same flaw elsewhere.
This prompted yet another proposal:
#[size]H([type] [rehash-size] [rehash-threshold] (ki vi)*)
e.g. #65H(EQL 101 65 (FOO 37) (BAR 42))
along with alternative settings for *PRINT-HASH*, NIL, T, :BRIEF, where the
latter would leave out all of the options.
- - - - Additional Comments - - - - -
you still can't
call the objects "first class" if the printed representation cannot be
read in as an equivalent copy; and the fact that CL has some other datatypes
that aren't "first class" doesn't argue for doing something substandard
for hash-tables.
One problem with the currently proposed #H notation is that it provides
no way to specify a rehash-size or rehash-threshold. This should not be
a fatal flaw, though. The #() notation is also incomplete: it cannot
indicate whether the vector has a fill pointer, nor can it show when the
element-type is something more specific than T. The latter problem is
also shared by #nA notation.
I think this is a fatal flaw. The fact that *some* complex classes of
arrays also share this fatal flaw is no argument for retaining it. It
is still the case that simple arrays of the more common element types
do not have the flaw; and several years ago there was some discussion
on how to fix other manifestations of the flaw on multi-dimensional arrays.
∂08-Oct-88 1902 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU disk rates
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Oct 88 18:43:36 PDT
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sat 8 Oct 88 18:39:34-PDT
Message-ID: <qovIs@SAIL.Stanford.EDU>
Date: 08 Oct 88 1839 PDT
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: disk rates
To: faculty@SCORE.Stanford.EDU
While disk charges on SAIL are still grossly too high, I misunderstood
a reference to charges on Polya increasing as referring to SAIL. On
SAIL they decreased. My apologies.
∂08-Oct-88 1956 X3J13-mailer Issue: LISP-SYMBOL-REDEFINITION (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 19:56:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 88 19:52:28 PDT
Date: 8 Oct 88 19:52 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: LISP-SYMBOL-REDEFINITION (Version 3)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-195228-2477@Xerox>
!
Issue: LISP-SYMBOL-REDEFINITION
References: Cleanup issue PACKAGE-CLUTTER
CLtL pp 67-69 Defining named functions
Category: CLARIFICATION
Edit history: Masinter, Version 1, 17-Sep-88 from (Kolb, 14-Aug-87)
Masinter, Version 2, 7-Oct-88
Masinter, Version 3, 7-Oct-88, fix typos
Problem description:
Is it legal to redefine Common Lisp functions? There is no explicit
prohibition, and many implementations do allow redefinition of
functions in the Lisp package.
CLtL only says that special forms can not be redefined. But this doesn't
solve the general problem of redefining system functions.
Proposal LISP-SYMBOL-REDEFINITION:DISALLOW
The results of redefining as a function any of the functions,
macros, or special forms defined in the LISP package are unspecified;
similarly, the result of lexically defining (with FLET, LABELS or
MACROLET) any function or macro in the LISP package is unspecified.
Clarify that, as implied by CLtL p. 69, it is an error to rebind
any symbol in CL defined as a constant.
The results of applying TRACE to any function in the LISP package is
unspecified.
Following the proposed definition of "results are unspecified", this means that
implementations may signal an error, or other unspecified behavior may
ensue. For example, programming environments may warn the user about
redefinition of LISP symbols and then allow them. Some environments may
distinguish between functions that are safe to redefine and those that are
not.
Examples:
The behavior of the construct:
(FLET ((OPEN (filename &key direction) (format t "Open called....")
(OPEN filename :direction direction)))
(with-open-file (x "frob" :direction ':output)
(format t "was Open called?")))
is unspecified; for example, the macro expansion of with-open-file might refer
to the OPEN function and might not.
(DEFUN CAR (X) (CDR X))
might signal an error.
Rationale:
This proposal is the only simple resolution of the problem description that
we can imagine that is consistent with current implementation techniques.
Allowing arbitrary redefinition of symbols in the LISP package would place
severe restrictions on implementations not to actually use those symbols in
macro expansions of other LISP symbols, in function calls, etc. While some
looser restrictions might do for any particular Common Lisp implementation,
there seems to be no good way to distinguish between those symbols that are
redefinable and those that are not.
In general, programs can redefine functions safely by creating new symbols in
their own package, possibly shadowing the name.
Current practice:
Many Lisp environments have some mechanism for warning about redefinition of
Lisp symbols and preventing accidental redefinition while allowing it where
necessary (e.g., to patch the Lisp system itself, fix a bug, add an
optimization.)
Fewer check for lexical redefinition, since such redefinition is not as
dangerous. Certainly, there are some symbols that are never used in macro
expansions of the standard Common Lisp macros. However, implementations do
differ on the behavior of macro expansions.
Cost to Implementors:
This proposal clarifies the status quo -- that the results are unspecified. It
allows and encourages implementors to check for such redefinition, but does not
require it.
Cost to Users:
This proposal clarifies that implementations are free to check for a condition
that they might not have before, and may clarify that some current user code is
non-portable.
Benefits:
This issue frequently arises. Adopting this proposal would clarify a frequent
source of question about Common Lisp.
Cost of non-adoption:
Continued questions.
Esthetics:
Disallowing all redefinition is the simplest way of disallowing the ones that
really are trouble.
Discussion:
There have been various proposals for allowing users to extend the "protection"
mechanism to their own macros, functions, packages. These proposals seem like
they are environment issues and not language ones, however.
It is unfortunate that the restriction on reusing LISP package symbols in
FLET, LABELS or MACROLET is necessary, but the research into straightening out
the syntactic environment of macroexpansion isn't mature enough to put into
a standard yet.
∂08-Oct-88 2035 X3J13-mailer Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 20:35:06 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 20:32:13 PDT
Date: 8 Oct 88 20:32 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-203213-2505@Xerox>
!
Issue: MAPPING-DESTRUCTIVE-INTERACTION
References: MAPCAR, MAPLIST, ... (p128);
DOLIST (p126); MAPHASH (p285);
DO-SYMBOLS, DO-EXTERNAL-SYMBOLS, DO-ALL-SYMBOLS (pp187-188);
All functions using :TEST
Related-Issues: REMF-DESTRUCTION-UNSPECIFIED.
Category: CLARIFICATION
Edit history: 07-Mar-88, Version 1 by Pitman
09-Jun-88, Version 2 by Pitman
(merge Moon's comments and update current practice)
Problem Description:
The interaction of mapping functions and DOLIST with destructive
operations on the list being operated on is unclear. For example,
if you destructively modify some tail of a list being mapped down,
does that affect the mapping process?
Proposal (MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE):
Clarify that it in general is an error (the effect is not defined
but in general no error will be signalled) for code executed during a
"structure traversing" operation to destructively modify the
structure in a way that might affect the ongoing traversal operation.
For list traversal operations, this means that the cdr chain of the
list may not be destructively modified.
For array traversal operations, the array may not be adjusted and
its fill-pointer, if any, may not be changed.
For hash tables, new elements may not be added or deleted EXCEPT
that the element corresponding to the current hash key may be
changed or removed.
For packages, new symbols may not be interned in or uninterned from
the package being traversed or any package that it uses EXCEPT that
the current symbol may be uninterned from the package being traversed
in a DO-SYMBOLS.
Note: This proposal is intended to clarify restrictions on user code
for use with structure manipulators which are not inherently
destructive. Other operators, such as DELETE-DUPLICATES or NREVERSE,
may have much more complicated restrictions and are intentionally not
treated by this proposal. See the issue REMF-DESTRUCTION-UNSPECIFIED
for more discussion of such issues.
Test Case:
(LET* ((L (LIST 'A 'B 'C)) (LL L) (I 0))
(DOLIST (FOO L)
(INCF I)
(IF (EQ FOO 'B)
(SETF (CDR LL) NIL)
(POP LL)))
(LIST I L)) might return (2 (A B)) or (3 (A B)), for example.
Rationale:
This clarifies the status quo.
Also, the likelihood that the user will want to destructively alter a
structure while it is being traversed is low. The likelihood that such
code would be readable and maintainable is also low. The likelihood
that a compiler could do some interesting optimization if this point
were not pinned down is high enough to be the overriding consideration
in this case.
Current Practice:
The implementation of DOLIST in Symbolics Genera, KCL, and PopLog Common Lisp
returns (3 (A B)) for the test case.
Cost to Implementors:
None. This simply makes the status quo explicit.
Cost to Users:
Technically none. People who were mistakenly assuming that CLtL guaranteed
things which it does not might be inclined to rewrite their code in a more
portable way.
Cost of Non-Adoption:
Users would be less informed.
Benefits:
users would be more informed.
Aesthetics:
Some might say it would be clearer to define this one way or the other, but
advocates of both camps exist and their arguments are fairly symmetric.
In any case, since this is a proposal to preserve the status quo, it has no
major impact on aesthetics.
Discussion:
This idea for this proposal was suggested by the Japanese community.
Pitman drafted the formal proposal and supports the EXPLICITLY-VAGUE proposal.
Moon generally supported version 1 of this proposal, but had some specific
criticisms about weakness of the wording which this version is an attempt to fix.
∂08-Oct-88 2043 X3J13-mailer Issue: PACKAGE-CLUTTER (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 20:43:50 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 20:40:55 PDT
Date: 8 Oct 88 20:40 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: PACKAGE-CLUTTER (Version 4)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-204055-2507@Xerox>
!
Issue: PACKAGE-CLUTTER
References: LISP, USER, SYSTEM packages (p181)
Related issues: LISP-SYMBOL-REDEFINITION, DEFPACKAGE,
MAKE-PACKAGE-USE-DEFAULT, IN-PACKAGE-FUNCTIONALITY
Category: CHANGE/CLARIFICATION
Edit history: 07-Jul-88, Version 1 by Pitman
23-Sep-88, Version 2 by Masinter
5-Oct-88, Version 3 by Masinter
7-Oct-88, Version 4 by Masinter (response to KMP)
Problem Description:
CLtL specifies that
``The package named LISP contains the primitives of
the Common Lisp system. Its external symbols include
all of the user-visible functions and global variables
that are present in the Common Lisp system, such as
CAR, CDR, *PACKAGE*, etc. Almost all other packages will
want to use LISP so that these symbosl will be accessible
without qualification.''
It specifies "all" but not "all and only".
Some implementations place their extensions in the Lisp package.
Nothing in CLtL explicitly prohibits this, but it leads to problems
in general. For example:
- A user defining a function by a name not mentioned in CLtL may be
surprised to clobber a system function in some implementations
- In one particular implementation, the variable HELP was a system
constant, so that ((LAMBDA (HELP) ...HELP...) "Press ? for help.")
signalled a correctable error (asking what variable to bind
instead of HELP :-).
Proposal (PACKAGE-CLUTTER:REDUCE):
Specify that, not only must the LISP package contain at least all of the
symbols listed in the standard, it will have no other external symbols.
(The LISP package may have additional internal symbols.)
Symbols on the LISP package may have function or macro
definitions, top level value or SPECIAL proclamations, or
type definitions only if explicitly permitted in the specification.
That is, a program is valid Common Lisp if it assumes that
this is true; for example, FBOUNDP will be false for all
external symbols of the LISP package except those documented
to be functions or macros; BOUNDP will be false for all
those except those documented to be variables,
and portable programs can use symbols in the LISP package
as local lexical variables with the presumption that the variables
are not proclaimed special, except for those variables specified
as constants or variables.
(The proposal LISP-SYMBOL-REDEFINITION addresses the
converse; that is, what user programs are allowed to do.)
Eliminate the requirement that the initial Common Lisp system
have a package named "SYSTEM". Specify that implementations may
have several other packages available, that these should be
documented. If it is appropriate, the standard might contain
as an example that implementations might have a package named
"SYSTEM".
Clarify that the "USER" package may have additional symbols interned
within it and that it may :USE other implementation-specific packages.
Examples:
#1: The symbol HELP may not be on the LISP package because it is not
mentioned in CLtL.
#2: The symbol VARIABLE is specified to be on the LISP package (because
it is a valid second argument to the DOCUMENTATION function). Since
it is not defined as a variable, type, or function, however, it will
not initially be bound, defined as a type, or defined as a function,
macro or special form.
Rationale:
If extra symbols are permitted in the LISP package, users may be surprised
by relationships between the LISP package and other packages which they
did not expect, or may be surprised by functionality that they did not
expect. The degenerate case is:
(DEFCONSTANT LISP:A 'YOU-LOSE)
(DEFCONSTANT LISP:B 'YOU-LOSE)
(DEFCONSTANT LISP:C 'YOU-LOSE)
...
(DEFCONSTANT LISP:AA 'YOU-LOSE)
(DEFCONSTANT LISP:AB 'YOU-LOSE)
(DEFCONSTANT LISP:AB 'YOU-LOSE)
...etc.
Given such an implementation, even things like (LAMBDA (X) X) are not
valid because they attempt to bind "system constants". It is necessary
that the programmer be able to know for sure that an arbitrary name is
"free for use" and best way to conveniently assure this is to require
that the LISP package be unadulterated.
As for the additional definitions, there are situations where additional
definitions would cause a problem. For example, if a symbol on the Lisp
package were declared as a special variable even though that value was
not mentioned in the standard, that variable would behave incorrectly when
used as a lexical variable. Similarly, if a symbol in the lisp package
were defined as an implementation-dependent special form, problems might
result if a user redefined or even bound (as by FLET or MACROLET) that
name.
The LISP package is the foothold from which portable programs establish
their desired environment. Careful control is desirable to make sure
everyone is starting off on the right foot.
Current Practice:
Some implementations have been known to add additional symbols (usually
functional and/or variable extensions) to the LISP package.
Several implementations have restricted the LISP package to only contain
those symbols in CLtL. (The exact set was difficult to extract because not all
LISP package symbols appeared in the index of CLtL.)
Even in those implementations that have only the prescribed symbols in CLtL,
there can be extra definitions for those symbols. For example, in Symbolics Genera,
the symbols EVALHOOK, ROOM, and APPLYHOOK
are spuriously defined as special variables, and the symbol LAMBDA is defined
as a macro.
Performance Impact:
None
Cost to Implementors:
The actual cost of moving the symbols out of the LISP package in cases
where they are not already gone is quite small. However, if any
implementation really has to do this, it may have a number of suppositions
about what is in what package, and the changes could potentially be extensive.
Cost to Users:
This change is upward compatible with any portable program, but users
of a particular implementation's extensions may be forced to find their
functions in a different package, so there may be a measurable practical
cost.
In many cases where an extension symbol FOO is simply expected to have
been directly available (due to :USE "LISP"), it will work to just just
do (IMPORT 'new-home-package-for-foo:FOO) where the user's package is
declared.
In many cases where an extension symbol FOO is used by explicit package
prefix, such as LISP:FOO, it should be easy to search for `LISP:FOO' or
even `LISP:' to find the cases.
Cost of Non-Adoption:
The potential for the LISP package to be adulterated and for supposedly
portable programs to have difficulty getting a foothold in some
implementations will be `noticeably non-zero'.
Benefits:
Portability of some programs will be enhanced.
Aesthetics:
This change probably supports the naive expectation of most programmers
writing portable code.
Discussion:
This proposal basically affects what implementors are allowed to do;
it says that portable programs can rely on a standard initial package
structure with the same symbols in it. A separate proposal,
LISP-SYMBOL-REDEFINITION, discusses the restrictions on portable
programs as far as redefining LISP symbols.
Whether the USER package may contain symbols other than those
specified in the standard was controversial. The smart programmer
of portable code will never rely on the contents of the
USER package. However, if someone wants a completely empty
package that uses only Lisp, it's easy and portable to create one.
While it would improve portability slightly to disallow additional internal
symbols in the LISP package (since it affects what DO-SYMBOLS will do)
explicitly prohibiting a common practice didn't seem like the best way
to discourage a possibly troublesome implementation technique.
Implementors should be especially careful about accidentally
exporting unwanted additional definitions for symbols,e.g., a variable
definition for EVALHOOK which might show through because of
an unintended name collision.
It is likely that the recently included portions of the standard (CLOS and
the signal mechanism) will reside in their own packages. These externally
defined packages should have the same constraints as outlined for
the LISP package here.
There has been a suggestion that vendor-specific extensions should
be placed in a package named like ACME-COMMON-LISP for the "Acme"
company.
A registry of packages (as well as features, modules and other global
names) would be useful, although probably not a part of the language
standard, per se.
∂08-Oct-88 2055 X3J13-mailer Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 20:55:17 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 20:51:35 PDT
Date: 8 Oct 88 20:51 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-205135-2517@Xerox>
!
Issue: PEEK-CHAR-READ-CHAR-ECHO
References: READ-CHAR (p379), UNREAD-CHAR (p379), PEEK-CHAR (p379),
MAKE-ECHO-STREAM (p330), Streams (p327-328),
READ-PRESERVING-WHITESPACE (p376),
READ-DELIMITED-LIST (p377)
Category: CLARIFICATION/CHANGE
Edit history: 06-Mar-88, Version 1 by Pitman,
23-Jun-88, Version 2 by Pitman (remove interactive stuff)
8-Oct-88, Version 3 by Pitman & Masinter
Problem Description:
The interaction between PEEK-CHAR, READ-CHAR and streams made by
MAKE-ECHO-STREAM is not made adequately clear about how many times
a particular character may be echoed and at what time such echo
is permissible.
For example, given:
(WITH-INPUT-FROM-STRING (STRING-STREAM "A")
(LET ((*STANDARD-INPUT* (MAKE-ECHO-STREAM STRING-STREAM
*STANDARD-OUTPUT*)))
(LET ((CHAR NIL))
(PEEK-CHAR) (PRIN1 '---)
(PEEK-CHAR) (PRIN1 '---)
(SETQ CHAR (READ-CHAR)) (PRIN1 '---)
(UNREAD-CHAR CHAR) (PRIN1 '---)
(READ-CHAR))))
what is seen on the terminal? There are at least these possibilities:
[1] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR. The first time
a char is seen by READ-CHAR it's echoed, UNREAD-CHAR does not echo,
re-fetching the char by READ-CHAR doesn't echo.
A------------
[2] Characters are echoed whenever seen by PEEK-CHAR or READ-CHAR.
Characters are not unechoed by UNREAD-CHAR.
A---A---A---A---
[3] Characters are not echoed by PEEK-CHAR but are echoed by READ-CHAR.
No `unecho' action is done by UNREAD-CHAR.
------A------A
[4] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR. READ-CHAR echos
but UNREAD-CHAR does not `unecho'.
A---A---A------A
[5] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR. READ-CHAR echos
but UNREAD-CHAR unechos (a magic Erase character must be
presupposed for display terminals, a file stream that can randomly
access during output and/or back up must be presupposed for files,
paper terminals just lose):
A<Erase>---A<Erase>---A---<Erase>---A
[6] PEEK-CHAR is implemented by peeking and does not echo. The first
time a char is seen by READ-CHAR it's echoed, UNREAD-CHAR does not
echo, re-fetching the char by READ-CHAR doesn't echo:
------A------
This list is not believed to be exhaustive. It is only to illustrate
of the variety of possible ways in which the current specification can
be implemented without technically being in conflict with the written
word of CLtL. Obviously not all of these interpretations are considered
useful by all people, but usefulness has not been determined to be
criterial in satisfying the specification.
The description of streams (p327-328) is also [probably deliberately]
fuzzy on this issue as it relates to operating systems on which echoing
is done by the operating system. That is, some systems are line-at-a-time
and all READ-CHAR and PEEK-CHAR operations happen after issues of echo
have long since been resolved by a system call that reads and echos input
a line at a time. Other systems are character-at-a-time and these issues
hit home in a different way. It will probably be necessary to continue
leaving things slightly unspecified in order to accomodate the native
style of the variety of operating systems now trying to support Common
Lisp, but we should be more up front about the game we are playing. (For
example, code which must port between character-at-a-time and
line-at-a-time systems must be more careful about whether it does
newline-preceded or newline-terminated output than many CL programmers
might realize given the current wording.) Additionally, though, we should
be on the lookout for less ambitious goals involving only partial
compatibility to improve the situation wherever we can find a way to.
Abstract functions READ-PRESERVING-WHITESPACE and READ-DELIMITED-LIST
are implicitly affected by any decisions made on this issue since their
descriptions involve the use of UNREAD-CHAR and PEEK-CHAR, respectively.
Proposal (PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR):
Ammend the description of READ-CHAR to say that when the stream is
an echo stream (a stream created by MAKE-ECHO-STREAM), the character
will be echoed on the stream the first time those characters are seen.
(Characters which are not echoed by READ-CHAR are those which were
put there by UNREAD-CHAR and hence are assumed to have been echoed
already by a previous call to READ-CHAR.)
Ammend the description of UNREAD-CHAR to say that when the stream
is an echo stream (a stream created by MAKE-ECHO-STREAM), no attempt
will be made to undo any echoing of the character which might already
have been done on the stream. However, characters placed on the
stream by UNREAD-CHAR will be marked in such as way as to inhibit
later re-echo by READ-CHAR.
Ammend the description of PEEK-CHAR to say that when the stream is
an echo stream (a stream created by MAKE-ECHO-STREAM), characters
which are only peeked at are not echoed. Note however that in the
case that the PEEK-TYPE argument is not NIL, the characters which
are passed by PEEK-CHAR are treated as if by READ-CHAR, and so are
echoed unless they have been marked otherwise by READ-CHAR.
Ammend the description of abstract input functions
READ-PRESERVING-WHITESPACE and READ-DELIMITED-LIST to acknowledge
that they are implicitly affected by these new echoing rules of
READ-CHAR, UNREAD-CHAR, and PEEK-CHAR.
Note: This is consistent with behavior [6] in the problem description.
Clarify that the echo behavior of interactive streams such as
*TERMINAL-IO* continues to be implementation dependent.
Rationale:
Although this is not known to be in use in any particular system,
nothing prevents its use. It proposes a more rational interpretation
of the echoing behavior of UNREAD-CHAR which might make it possible
for programmers concerned about echo behavior not to have to shy
away from UNREAD-CHAR. (It would probably also improve the behavior
of READ-PRESERVING-WHITESPACE with regard to echoing, since its
description mentions using UNREAD-CHAR.)
Correct echoing behavior is important to programs which do batch
processing, parsing, etc. Allowing multiple or premature echoing
is clearly unsatisfactory.
Current Practice:
A wide variety of behaviors are in use.
Cost to Implementors:
Unknown.
The code to implement the proposed change itself is probably fairly
localized.
In some operating systems, there may be echoing constraints which
are overlooked here.
In some cases, there may be second order effects in the system
itself which would also require a somewhat less predictable amount
of work to fix.
Cost to Users:
Any change is effectively upward compatible since the previous
behavior is so ill-specified.
Most users probably naively expect (perhaps even without realizing
it explicitly) that echoing will take care of itself. That is, they
probably expect that echoing will occur at the time of the
READ-CHAR and probably do not give a lot of thought to the effect
of PEEK-CHAR. As such, FIRST-READ-CHAR probably best supports most
of their naive intuitions.
Cost of Non-Adoption:
The streams returned by MAKE-ECHO-STREAM would continue to be
significantly hard to use portably.
Benefits:
A number of applications involving of parsers, batch script
interpreters, and such would be possible to implement
straightforwardly and portably.
Aesthetics:
?
Discussion:
Pitman supports PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR because
he feels it is more practically coherent. However, he says he has
only mental exercises and no actual personal experience upon which
to base that belief.
Version 1 of this proposal treated interactive streams on par
with echo streams, but while people agreed that this issue is
a severe portability problem, some considered that the treatment
of interactive streams got involved in operating system issues
that were beyond the scope of the standard, so that part of the
text was removed.
∂08-Oct-88 2106 X3J13-mailer PRINT-CIRCLE-STRUCTURE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:06:50 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 88 21:01:23 PDT
Date: 8 Oct 88 21:01 PDT
Sender: masinter.pa@Xerox.COM
Subject: PRINT-CIRCLE-STRUCTURE (Version 3)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-210123-2526@Xerox>
!
Issue: PRINT-CIRCLE-STRUCTURE
References: pp. 370-371
Category: CLARIFICATION
Edit history: Version 3, Masinter 10/8/88 (minor cleanup)
Version 2, Chris McConnell 10/05/88
Version 1, Chris McConnell 09/20/88
Problem description:
When a lisp object is printed that points to a structure with a user
defined print-function and there is a pointer back to the containing
object, the printer will recurse infinitely even when *print-circle*
is set to T. This prevents printing circular structures that point to
objects that cannot be printed and prevents the development of new
printed representations that can be read by the reader.
Proposal PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK:
When *print-circle* is T, a user defined print-function can print
objects to the supplied stream using WRITE, PRIN1, PRINC, or FORMAT
and expect circularities to be detected and printed using #n# syntax.
If a user defined print-function prints to a stream other than the one
that was supplied, then circularity detection starts over for that
stream.
Test Cases/Examples:
;;;
;;; Define a structure that can be circular and that has a slot with a
;;; value that cannot be printed.
;;;
(defstruct (TEST (:print-function print-test))
ptr
(function #'(lambda (x)
(error "No function is defined."))))
;;;
;;; This print function generates a machine readable printed
;;; representation for a structure with a slot that cannot be printed.
;;;
(defun PRINT-TEST (structure stream depth)
(format stream "#S(TEST PTR ~S)" (test-ptr structure)))
;;;
;;; Define two structures that point to each other. If this
;;; expression successfully evaluates at the top level, then the
;;; printed result should look like:
;;; #1=#S(TEST PTR #S(TEST PTR #1#))
;;;
;;; If it does not work then it will generate an infinite printed
;;; representation.
(setf *print-circle* t
*a (make-test)
*b (make-test)
(test-ptr *a) *b
(test-ptr *b) *a)
Rationale:
Many structures are circular and point to complex data structures that
may include things like closures that cannot be printed. It should be
possible to define a way to print these data structures such that they
can be read back in. Common LISP provides two mechanisms for these
problems (*print-circle* and the :print-function option to defstruct),
but they do not currently work together in most implementations.
Current practice:
Lucid 3.0 and the Genera do work on the test case. (Previous versions
did not.) KCL, Coral and Franz do not work.
Cost to Implementors:
Lucid and Symbolics have done it, so they could give an idea of the
difficulty. Possible techniques include passing the printer state
information by dynamic binding rather than by explicit parameters or
by supplying an internal stream to the user print function.
Cost to Users: None
Cost of non-adoption:
Currently this problem causes an infinite recursion whenever a user
print-function prints a lisp object that contains the structure that
is being printed by the user print function. If nothing is done, this
error will remain and the whole effort to provide a portable printed
representation of LISP structures is of minimal usefulness. In almost
any real application, there are circular structures with non printable
objects such as closures and hash tables that need to be printed. In
addition the development of printers for new reader macros becomes
much more of an effort then it should be since it requires
reimplementing the complete circularity detection mechanism.
Benefits:
If the proposal is adopted, then it becomes easier to define new
printed representations that are compact and that still capture the
information needed to rebuild data structure instances. It allows a
printed representation to hide the actual details of how a data
structure is implemented in terms of underlying LISP data structures.
Esthetics:
This proposal increases the uniformity of the language by making
*print-circle* work in all cases including where a user has defined a
new print function.
Discussion:
At least three members of the cleanup committee read this and think
it looks good.
∂08-Oct-88 2112 X3J13-mailer DRAFT Issue: PROCLAIM-LEXICAL (Version 8)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:11:58 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 88 21:06:34 PDT
Date: 8 Oct 88 21:06 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: PROCLAIM-LEXICAL (Version 8)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-210634-2532@Xerox>
We're still working on this one.
!
Status: DRAFT
Issue: PROCLAIM-LEXICAL
References: variables (p55), scope/extent (p37), global variables (p68),
declaration specifiers (p157)
Category: CLARIFICATION/ADDITION
Edit history: Version 2 by Rees 28-Apr-87
Version 3 by Moon 16-May-87
Version 4 by Masinter 27-Oct-87
Version 5 by Masinter 14-Nov-87
Version 6 by Pitman 15-Sep-88
(major revision, for review by Jonathan Rees and Jeff Dalton)
Version 7 by Pitman 24-Sep-88
(minor revisions based on comments from Rees and Dalton)
Version 8 by Pitman 06-Oct-88 (merge recent discussion)
Status: For Internal Discussion
Problem Description:
Although local variables in Common Lisp may be `special' or `lexical,'
global variables (with the exception of named constants) may currently
only be `special.'
The Scheme language permits free variable references to refer to global
bindings. Their experience suggests that such usage would be useful to
the Common Lisp community. The absence of such a facility in Common Lisp
is a barrier both culturally (to the sharing of ideas) and technically
(to the sharing of code).
SPECIAL proclamations are uncontrollably pervasive. There is no way
to locally override or globally undo a SPECIAL proclamation.
Background/Analysis:
Variable evaluation may be viewed in Common Lisp as a search through
a set of environments to find a binding, and then the dereferencing of
that binding. The environments with which Common Lisp deals are
Lexical (L), Dynamic (D), and Global (G).
A SPECIAL declaration for a variable amounts to a request that the
variable be resolved by searching first the Dynamic and then the Global
environment (DG).
As currently described in CLtL, lexical variable reference searches
only the Lexical environment (L).
Because undeclared free variables in the interpreter are implicitly
declared SPECIAL by most (perhaps all) implementations, this amounts
to a search of Lexical, Dynamic, and Global (LDG). However, the
accompanying warnings in many implementations make it clear that this
behavior is not intended to be taken seriously.
Constants are looked up solely in the Global environment (G). They
have other properties as well, of course.
In the Scheme language, the default lookup is first Lexical, then
Global (LG). Providing compatibility for Scheme code is, and more
generally for a Scheme working style is therefore difficult because
Common Lisp does not provide the LG search style.
The issue of whether a variable can be assigned is orthogonal.
The issue of whether a variable can be bound and, if it can be, which
environment is used for the new binding is orthogonal.
Proposal (PROCLAIM-LEXICAL:LG):
Provide a new declaration (and proclamation) called LEXICAL which does
LG lookup. That is, variables declared LEXICAL would be looked up first
in the lexical environment (L) and then in the global environment (G)
if not found in the lexical.
Clarify that dynamic binding does DG lookup. That is, variables
declared SPECIAL would be looked up first in the dynamic
environment (D) and then in the global environment (G) if not found
in the lexical. Further clarify that SYMBOL-VALUE does DG lookup.
Define that a dynamic binding of a variable creates a new binding
in the dynamic environment (D) leaving the global environment (G)
unaffected.
Define that a lexical binding of a variable creates a new binding
in the lexical environment (L), leaving the global environment (G)
unaffected.
Note that an assignment to a variable which is bound in the global
environment (G) will affect lexical (LG) lookups for which there is
no lexical (L) binding and dynamic (DG) lookups for which there is
no dynamic (D) binding.
Note that these restrictions describe an abstract model, not a
concrete implementation. An implementation may still choose to
implement dynamic binding as either deep or shallow, but some
searching may be necessary to find the global cell in shallow bound
implementations [unless dynamic binding has been forbidden for
that variable].
Like SPECIAL declarations (and unlike type declarations),
compilers and interpreters would be required to notice and
respect this declaration.
Test Case:
#1: (proclaim '(lexical x))
(setq x 1)
(defun f (fn) (list x (funcall fn)))
(defun g (fn)
(let ((x 2))
(declare (special x))
(funcall fn #'(lambda () x))))
(g #'f) => (1 2)
#2: ; Warning: It is unlikely that any serious program would
; be written in so obscure a manner as this example.
; This just tests the fringe cases.
(proclaim '(lexical x))
(proclaim '(special y))
(setq x 1 y 2)
(defun tst ()
(let ((x 3) (y 4))
(locally (declare (special x) (lexical y))
(list x y
(funcall (let ((x 5) (y 6))
#'(lambda () (list x y))))))))
(tst) => (1 2 (5 4))
If the results of this example confuse you, keep in mind
that the results of code like this would be somewhat
confusing no matter what the chosen semantics because the
code itself is far from perspicuous.
An explanation of this behavior, which some people find less
than intuitive because of the bizarre choice of constructs:
X gets bound lexically to 3 because X is [pervasively]
proclaimed LEXICAL.
Y gets bound specially to 4 because Y is [pervasively]
proclaimed SPECIAL.
Reference style for name X is changed to SPECIAL, making
lexical X=3 invisible.
Reference style for name Y is changed to LEXICAL, making
dynamic Y=4 invisible.
Global X=1 and global Y=2 are first two elements of list.
X gets bound lexically to 5 because X is [pervasively]
proclaimed LEXICAL.
Y gets bound specially to 6 because Y is [pervasively]
proclaimed SPECIAL.
Closure is returned, capturing [lexical] X=5 but not
[special] Y=6.
Dynamic binding of Y to 6 disappears, dynamic binding
of Y to 4 reverts.
Closure is funcalled, returning captured X=5 and dynamically
active Y=4 in a list which becomes third list element.
Rationale:
This mechanism provides a simple and straightforward answer to
the problems stated above.
Current Practice:
Probably no one implements this.
Cost to Implementors:
A fair amount compiler work would probably be needed. Some compilers
may have hooks for most of this already laying around, but some may not.
Note well that this proposal does not require separate global lexical
and dynamic cells, so the data storage layout of Lisp need not change.
Moon says...
I have now thought of an efficient way to do this on Lisp machines,
using invisible pointers, and another efficient way to do it on
stock hardware, using one extra instruction on every global
reference of one or the other sort, plus a few extra instructions
in SPECIAL binding and unbinding. Given that, I no longer object
to the proposal as unimplementable.
It doesn't just require a few compiler changes, it requires some
reimplementation of the representation of global variables, with
concomitant changes to the compiler, the loader, the interpreter,
and probably the debugger. Every symbol now potentially has two
values accessible from the interpreter (the current SPECIAL and
the global LEXICAL) and you need the corresponding new data
structure to keep track of that.
Rees suggests...
In shallow-bound implementations, implementors may have to add a
small run-time routine that searches the dynamic saved-binding
stack to look for the global value in the case where the variable
has been dynamically bound. One might want a bit (or a count)
somewhere (perhaps in the symbol itself) to speed up the common
case of access to a global binding of a variable that hasn't been
dynamically bound; without some kind of optimization, you have to
search the whole saved-binding stack on every reference to a
free [lexical] variable.
While naively you might think you'd incur the cost of clearing the
valid bit on every dynamic binding (not acceptable), in actuality
the bit is a static property of programs (PROGV excepted). So the
only places you ever need to clear FOO's valid bit are in PROGV,
in the interpreter, and when FASLOADing code that contains a compiled
dynamic binding of FOO.
Cost to Users:
For the most part, this change is upward compatible.
Some code-walking tools would have to change.
Cost of Non-Adoption:
It would continue to be difficult to share code with Scheme.
New CL users coming from the Scheme community would be confused by
their sometimes inability to map what they know about variable binding
into the CL model of variable binding.
Some interesting native CL applications would be impossible to write
in a syntactically convenient style.
Benefits:
Enhanced flexibility of expression.
Rationalization of the semantics of dynamic variables.
Aesthetics:
Improved appeal to a certain sector of the programming community.
Discussion:
Rees points that it is an oversimplification to describe Scheme's
binding simply as LG since they have no Dynamic environment and
there is no way to distinguish LG and LDG. However, the reasons he
prefers LG are:
1. It's nice for readability and understandability to have a
declaration which tells you that a variable will not be
dynamically bound.
2. It's nice for performance in deep-bound implementations to have a
declaration that says that no search will be needed.
Of course, he notes, there could be a counter-argument to item 2
(in favor of LDG) in order to prefer shallow bound implementations,
but that still would not defeat the argument in item 1. Rees believes
that LG is slightly preferrable, but that LDG would be essentially
adequate for most of his needs.
Pitman supports PROCLAIM-LEXICAL:LG and believes that giving LDG the
name LEXICAL would be a serious mistake, leaving open the door for
program bugs due to accidental binding of variables presumed by the
programmer not to be bound. If someone (Moon?) seriously wanted LDG
type variables in addition to LG variables (under a name other than
LEXICAL), Pitman would not object.
Dalton expressed support for PROCLAIM-LEXICAL:LG (Version 6).
He observes that another reason for opposing LDG is that it suggests
the possibility that someone might want DLG. LG is simpler and still
accomplishes the stated purpose. He adds ``I would like to be able
to explain the global environment as a sort of giant, extensible
LET abound everything. This proposal seems to get fairly close.''
It would be possible to submit a proposal for a GLOBAL (G) declaration
under separate cover if anyone (Xerox?) was interested. Pitman thinks
this would be an interesting idea. Dalton points out, however, that
already with this proposal there is enough power to at least deal with
globals -- albeit circuitously. For example, to reference a global
variable X, one could write subroutines such as:
(defun global-x () (declare (lexical x)) x)
(defun set-global-x (value) (declare (lexical x)) (setq x value))
Eg, consider:
(defun f (x) (+ (global-x) x))
In principle, we could imaging saying that free variables should be
lexical by default, but that would only reduce error checking to no
good end. To be really useful, this proposal will need to be followed
by a proposal for primitives analogous to DEFVAR and/or DEFPARAMETER
but for lexical variables. However, since arguments over syntax are
likely to have plenty of issues of their own, we've separated this
proposal for primitive functionality from issues of syntax which
can be dealt with separately once this is passed.
Moon expressed concerns about the efficiency issues but after
thinking about it for a while convinced himself that this is
efficiently implementable both on stock and special purpose hardware.
JonL expressed concerns about the last-minute nature of this change,
which he sees as untested.
Dalton suggests that an alternative solution to the speed issue
might be possible to obtain by restricting a particular variable to
be either LEXICAL or SPECIAL but not both.
Dalton points that even if people don't like the details here, there
must be a better fallback solution than "do nothing". Pitman agrees
heartily.
----- End Forwarded Messages -----
∂08-Oct-88 2129 X3J13-mailer DRAFT Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:29:04 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 21:24:26 PDT
Date: 8 Oct 88 21:24 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-212426-2546@Xerox>
There were at least 20 messages after this draft was circulated
among the cleanup committee; the discussion is too long to append
and there is currently no summary of it. However, this issue
was last raised in November 1987; perhaps some resolution will
be more forthcoming.
!
Issue: REMF-DESTRUCTION-UNSPECIFIED
References: (SETF (GET ...) ...), REMPROP, (SETF (GETF ...) ...),
REMF (pp165-167); NREVERSE (p248); DELETE, DELETE-IF,
DELETE-IF-NOT, DELETE-DUPLICATES, NSUBSTITUTE,
NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT (pp254-256); NCONC,
NRECONC (p269); NBUTLAST (p271); NSUBST, NSUBST-IF,
NSUBST-IF-NOT (p274); NUNION, NINTERSECTION,
NSET-EXCLUSIVE-OR (pp276-279).
Category: CLARIFICATION
Edit history: 11-Feb-87, Version 1 by DLA@Stony-Brook.SCRC.Symbolics.COM,
29-Oct-87, Version 2 by Pitman (flesh out proposals)
Status: For Internal Discussion
Problem Description:
Currently, the exact nature of the side-effect performed by list
modification routines is not specified.
Test Cases:
For GETF...
(SETQ FOO (LIST 'A 'B 'C 'D 'E 'F)) ==> (A B C D E F)
(SETQ BAR (CDDR FOO)) ==> (C D E F)
(REMF FOO 'C)
BAR ==> ??
In Symbolics Common Lisp, BAR holds (C D E F).
CLtL allows other interpretations. eg, BAR might hold
(C), (NIL), (C NIL) or (C D).
In MAKE-EXPLICITLY-DEFINED, BAR would hold (C D E F).
In MAKE-EXPLICITLY-VAGUE, any of these interpretations (and
others as well) would still be valid
For DELETE...
(SETQ FOO (LIST 'A 'B 'C)) ==> (A B C)
(SETQ BAR (CDR FOO)) ==> (B C)
(SETQ FOO (DELETE 'B FOO)) ==> (A C)
BAR ==> ??
(EQ (CDR FOO) (CAR BAR)) ==> ??
In Symbolics Common Lisp, these last two expressions return ((C)) and T.
In MAKE-EXPLICITLY-DEFINED, they would return (B C) and NIL.
In MAKE-EXPLICITLY-VAGUE, either of these interpretations (and others
as well) would be valid.
Proposal (REMF-DESTRUCTION-UNSPECIFIED:MAKE-EXPLICITLY-DEFINED):
Clarify that the destructive behavior of the following operators
is restricted as indicated. Note well -- only the side-effect behavior
of these functions is discussed here; these remarks are not intended
as complete functional descriptions.
(SETF (GETF place indicator) value)
is permitted to either SETF place or to SETF the CADR of what
(GET-PROPERTIES place (LIST indicator)) would return.
(REMF place indicator)
is permitted to either SETF place or to SETF the CDR of the
part of the top-level list in place which points to what
(GET-PROPERTIES place (LIST indicator)) would return.
In particular, the two removed cells may not be destructively
modified.
(SETF (GET symbol indicator) value)
is constrained to behave exactly the same as
(SETF (GETF (SYMBOL-PLIST symbol) indicator) value).
(REMPROP symbol indicator)
is constrained to behave exactly the same as
(REMF (SYMBOL-PLIST symbol) indicator).
(NREVERSE sequence)
when sequence is a list is permitted to setf the CDR of any
subtail of sequence to point to any other subtail of sequence,
to NIL, or to any piece of newly created list structure.
when sequence is an array is permitted to re-order the elements
of the given sequence in order to produce the resulting array.
(DELETE object sequence ...)
when sequence is a list is permitted to SETF the CDR of any part
of that list which points to a tail whose car is object.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(DELETE-IF test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (FUNCALL test ITEM))
...).
(DELETE-IF-NOT test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (NOT (FUNCALL test ITEM)))
...).
(DELETE-DUPLICATES sequence ...)
when sequence is a list is permitted to SETF the CDR of any part
of that list which points to a duplicated element that is to be
removed.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
(NSUBSTITUTE-IF-NOT new-object test sequence ...)
when sequence is a list is permitted to SETF the CAR of any part
of that list which must be replaced by NEW-OBJECT.
when sequence is an array is permitted to SETF the contents of
any cell in that array which must be replaced by NEW-OBJECT.
Note, however, that since this side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NCONC . lists)
is permitted to SETF the CDR of the LAST of any of its argument
lists which are non-null, except the last argument.
(NRECONC list tail)
is constrained to have side-effect behavior equivalent to:
(NCONC (NREVERSE list) tail).
(NBUTLAST list ...)
is permitted to SETF the tail of its argument list whose CDR
is LAST of that argument LIST.
(NSUBST new-object old-object tree)
(NSUBST-IF new-object test tree)
(NSUBST-IF-NOT new-object test tree)
is permitted to SETF any part of the TREE of conses which must
be replaced by NEW-OBJECT.
Note, however, that since the tree might be a degenerate tree
containing no conses and since the side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NUNION list1 list2 ...)
(NINTERSECTION list1 list2 ...)
(NSET-EXCLUSIVE-OR list1 list2 ...)
is permitted to setf the CDR of any subtail of either list to point
to any other subtail of either list, to NIL, or to any piece of newly
created list structure.
Rationale:
This implements what some users will consider the status quo.
In most cases, it is consistent with what naive implementations of
these functions might do.
Benefits:
By being more explicit about the side-effects which can be expected,
users can write programs which more reliably exploit these side-effects.
In some case, this may make certain programming problems easier.
Certain naive user assumptions and assumptions based on the behavior
of older lisp dialects would be supported.
Compatibility with older Lisp dialects (eg, Zetalisp, Maclisp, ...)
would generally be better.
Gratuitious porting hassles would be naturally lessened slightly.
In situations where programmers inadvertently depended upon the specific
nature of a particular operator's side-effect, chances would be much
greater that the code would be portable because there would be less room
for implementations to vary.
Non-Benefits:
Implementations may be forced to be less efficient than they could be
if the MAKE-EXPLICITLY-VAGUE proposal were adopted, since that proposal
allows implementors more room for optimization. Some existing
implementations will be forced to become less efficient to meet the
standard, degrading performance of existing applications which do not
rely on the new features with no benefit to those existing applications.
Adoption Cost:
Some implementations would have to change. For example, Symbolics Common
Lisp makes more unusual assumptions about what it can modify than some
of the above rules allow.
Conversion Cost:
Probably none. Users must currently tread lightly since they really
have no idea in many cases what kind of side-effect is really likely to
occur when they use some of the existing destructive operators.
Some implementations might be forced to change, and since some user
programs might have depended on the old behavior, programs which used
to run might be broken in the transition. However, in most cases where
an implementation guarantees any behavior, it is likely to be the one
suggested here. Systems which have other behaviors are likely to warn
users not to depend on the specifics of those behaviors. So the incidence
of problems arising in practice is likely to be very small, though
probably not nonzero.
Aesthetics:
Some of these restrictions tend to expose more detail about the
implementation of these operators, turning them from abstract operations
into more concrete utilities. This is probably an issue that can be
addressed by appropriate information hiding in a User's Manual however.
No matter how unpleasant the presence of these somewhat concrete
restrictions may seem, the porting bugs which arise in their absence are
bound to seem more unpleasant to some users.
Proposal (REMF-DESTRUCTION-UNSPECIFIED:MAKE-EXPLICITLY-VAGUE):
Clarify that the destructive behavior of the following operators
is restricted as indicated:
(SETF (GETF place indicator) value)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(REMF place indicator)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(SETF (GET symbol indicator) value)
is constrained to behave exactly the same as
(SETF (GETF (SYMBOL-PLIST symbol) indicator) value).
(REMPROP symbol indicator)
is constrained to behave exactly the same as
(REMF (SYMBOL-PLIST symbol) indicator).
(NREVERSE sequence)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to re-order the elements
of the given sequence in order to produce the resulting array.
(DELETE object sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(DELETE-IF test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (FUNCALL test ITEM))
...).
(DELETE-IF-NOT test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (NOT (FUNCALL test ITEM)))
...).
(DELETE-DUPLICATES sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
(NSUBSTITUTE-IF-NOT new-object test sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to SETF the contents of
any cell in that array which must be replaced by NEW-OBJECT.
Note, however, that since this side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NCONC . lists)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given lists (except the last, which is not required to
be a list and must not be modified).
(NRECONC list tail)
is constrained to have side-effect behavior equivalent to:
(NCONC (NREVERSE list) tail).
(NBUTLAST list ...)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given list.
(NSUBST new-object old-object tree)
(NSUBST-IF new-object test tree)
(NSUBST-IF-NOT new-object test tree)
is permitted to SETF any part of the TREE of conses which must
be replaced by NEW-OBJECT.
Note, however, that since the tree might be a degenerate tree
containing no conses and since the side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NUNION list1 list2 ...)
(NINTERSECTION list1 list2 ...)
(NSET-EXCLUSIVE-OR list1 list2 ...)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given lists.
Rationale:
This is probably the status quo from a typical implementor's point of view.
Benefits:
Users would be discouraged from taking advantage of subtle details
of these destructive operations because such details would be explicitly
not guaranteed to be portable.
Implementations can improve performance of many of the above-mentioned
functions when they are not under the constraint to implement them
in a highly constrained fashion. For example, in Symbolics systems,
DELETE of a cdr-coded list could use the implementation primitive
%CHANGE-LIST-TO-CONS rather than RPLACD to avoid creating forwarding
pointers.
Garbage collection effectiveness can also be improved. For example,
all of the destructive operations which remove objects (eg, REMF)
could remove CAR pointers to removed objects which are more volatile
than the list itself, assisting the garbage collector and thereby
improving memory usage and paging performance.
Non-Benefits:
Users who inadvertently depend on side-effect behavior may be rudely
surprised when moving between implementations.
Compatibility with older Lisp dialects is diminished.
Adoption Cost:
None. This is the status quo for implementors.
Conversion Cost:
This change would not affect programs coded with "good programming
practice". That is, only programs which rely on currently undocumented
features would be in any danger of breaking. In fact, those programs
are already in such danger, and this change to the documentation would
just publicize it. The clarification would -encourage- good programming
practice by warning people to only obey the published contract of the
above-mentioned functions.
There is, however, no automatic technique for making this check for
programs already in error. Bugs due to unexpected side-effects are in
general among the hardest to reckon with.
Aesthetics:
Most of these functions implement abstract operations. For example,
REMPROP implements an abstract operation on a "property list".
Proper language design should not encourage people to delve below the
level of abstraction into the nitty gritty.
Discussion:
Conversation on the Common-Lisp mailing list has made it clear that
the current situation is not good because it does not make the designers'
intent clear. The list modification allowed should either be specified,
or explicitly documented as unspecified and up to the individual
implementation. If the list modification is specified, then programmers
can rely on the specification. If it is unspecified, then implementors
can take advantage of that to make their implementation more efficient.
Pitman believes that REMF-DESTRUCTION-UNSPECIFIED:MAKE-EXPLICITLY-VAGUE
may be better from a purist point of view, but strongly supports
REMF-DESTRUCTION-UNSPECIFIED:MAKE-EXPLICITLY-DEFINED
because of practical considerations related to reliably being able to
debug portable code, a stated priority of an ``industrial strength''
language such as Common Lisp. The more alike implementations are forced
to be, the better the chances that something that ran one place will run
another.
DLA, who raised this issue, disagrees strongly. He cites efficiency
and does not believe performance should be traded off for features
which reasonable code does not tend to use. Metering in Symbolics test
systems have shown that there are performance gains to be had by
allowing implementations flexibility in these areas. DLA believes that
if users want more predictability from these functions, they should
write private variants that implement whatever predictability they
require. Additionally, he argues that the implementation users expect
is not obviously the one chosen in MAKE-EXPLICITLY-DEFINED. For
example, many programmers have used NREVERSE for years and assumed that
it shuffled list elements rather than CDRs.
DLA points out that MAKE-EXPLICITLY-DEFINED is still lax enough that if
FOO holds (A B) and you do (SETF (GETF FOO 'A) 'C), FOO could be
(A C A B). We should be sure this doesn't get left vague if that
proposal is adopted.
----- End Forwarded Messages -----
∂08-Oct-88 2134 X3J13-mailer Issue: REQUIRE-PATHNAME-DEFAULTS (version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:34:30 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 21:30:41 PDT
Date: 8 Oct 88 21:30 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-213041-2554@Xerox>
!
Issue: REQUIRE-PATHNAME-DEFAULTS
References: *MODULES*, PROVIDE, REQUIRE, pp 188-191
LOAD, pp 426-427
Category: CHANGE
Edit history: Version 1 by Pierson 9/13/88
Version 2 by Pierson 9/19/88, change PROVIDE stuff per comments
Problem description:
PROVIDE and REQUIRE are a dual-purpose pair of functions that attempt
to provide multi-file Common Lisp programs with a single mechanism to
detect and correct incorrect load sequences. These functions were
also designed to be used for general file inclusion in Common Lisp.
Unfortunately, the file loading feature of REQUIRE is specified such
that it is inherently non-portable and environment dependent.
The instructions on CLtL pp. 189-191 on the placement of PROVIDE and
REQUIRE don't work because they ignore interactions with LOAD. If
PROVIDE is placed at the head of a file which fails to load correctly,
the module will be incorrectly recorded as loaded. If PROVIDE is
placed at the end of the file, as is the unofficial current practice
in some groups, it is not possible to REQUIRE a file that REQUIREs the
current file; thus mutually dependent modules cannot be correctly
defined.
Proposal (REQUIRE-PATHNAME-DEFAULTS:DECLARATIVE):
Remove the second argument from REQUIRE. Change the description of
REQUIRE to:
The REQUIRE function tests whether a module is already present
(using a case-sensitive comparison); if the module is not present,
REQUIRE signals a correctable error of type REQUIRE-ERROR. The
error can be corrected by loading the appropriate file(s).
Note that there is no requirement that a module consist of exactly one
file.
Change the description of PROVIDE to:
"The PROVIDE function adds a new module name to the list of
modules maintained in the variable *MODULES* and possibly performs
other implementation-dependant actions to indicate that the module
in question has been loaded."
(There is no need to make a corresponding change to the definition of
REQUIRE, because it doesn't mention *MODULES*.)
Add a new second paragraph to the section on LOAD (CLtL 23.4):
"Top level PROVIDE functions in files being loaded are handled
specially. The PROVIDE is executed in a temporary environment
such that the module will appear to have been loaded during the
remainder of the load of the current file and any files loaded,
whether directly or by REQUIRE, during the loading of the current
file. If an error occurs during the loading of the current file,
all modules PROVIDEd during the load of the current file will be
forgotten. Otherwise, all these modules will be "confirmed" at
this level of nested loading. (Note that an implementation which
uses *MODULES* as the only loaded module database can support all
of this by simply rebinding *MODULES* appropriately internally
and pushing the new modules onto the old binding at the end.)"
Test Cases/Examples:
(REQUIRE 'fft)
Would still be legal.
(REQUIRE 'fft "fft")
Would no longer be Common Lisp.
Rationale:
The file loading feature of REQUIRE is non-portable. Since we can't
figure out an acceptable portable solution, the feature should be
flushed. Making REQUIRE signal a correctable error gives the user an
easy out in interactive situations.
Current practice:
All implementations that I know of currently support a second argument
to REQUIRE. Lucid and KCL use the second argment at the pathname to
load relative to the current working directory.
Cost to Implementors:
All currently conforming implementations will have to make a small
change.
Cost to Users:
Any (non-portable) user programs that rely on the current behaviour of
REQUIRE will have to change. On the other hand, porting Common Lisp
programs from one system to another may well be simplified because
REQUIRE errors will always correctable.
Cost of non-Adoption:
Part of the documented functionality of REQUIRE will continue to
unavailable to portable (and many non-portable) programs.
Benefits:
PROVIDE and REQUIRE will be clearly restricted to a portable,
checking role.
Aesthetics:
This simplifies the language by removing an environment-dependent
feature.
Discussion:
Pierson supports this proposal.
This proposal creates an asymmetry in the handling of *MODULES* that
may bother some people.
Several people would like to simply eliminate PROVIDE and REQUIRE from
the language and either leave this language space empty or provide a
portable DEFSYSTEM standard. Others believe that PROVIDE and REQUIRE
are useful as a safety-net even in the presence of DEFSYSTEM. This
proposal attempts to reduce PROVIDE and REQUIRE to a well-defined
safety-net and leaves the question of DEFSYSTEM to a separate
proposal (which I don't intend to write).
∂08-Oct-88 2146 X3J13-mailer Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:45:52 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 21:40:35 PDT
Date: 8 Oct 88 21:40 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-214035-2555@Xerox>
!
Issue: ROOM-DEFAULT-ARGUMENT
References: ROOM (p442)
Category: ADDITION
Edit history: 12-Sep-88, Version 1 by Pitman
Problem Description:
Passing no argument to ROOM is not equivalent to any argument which
can be passed. This makes data-flow from another function which wants
to call ROOM inconvenient. Rather than simply passing a value through,
the correct calling sequence must be selected as well. For example,
one might have to do something like
(CASE FLAG
(:DEFAULT (ROOM))
((T NIL) (ROOM FLAG)))
where (ROOM FLAG) would suffice
Proposal (ROOM-DEFAULT-ARGUMENT:NEW-VALUE):
Specify that passing an argument of :DEFAULT is equivalent to passing
no argument to ROOM.
Test Case:
(ROOM ':DEFAULT) is functionally equivalent to (ROOM).
Rationale:
Minimal change needed to get around the stated problem.
Allows ROOM to be describable without reference to supplied-p
information.
Current Practice:
Symbolics Genera defines ROOM using &REST and looks for NIL, (T), or (NIL).
[This reduces its ability to do compile-time number-of-argument checking.]
Some other implementations probably have a magic undocumented value
to avoid use of a SUPPLIED-P argument.
Cost to Implementors:
Probably it involves negligible resources to change this.
In most implementations, the resulting code would probably look better.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
The description of ROOM will look yucky in the emerging specification.
The source code for ROOM will look yucky.
[How's that for objective? -kmp]
Error checking in some implementations may be sub-optimal.
Benefits:
The description of ROOM in the now-being-written specification would
be less complicated.
Aesthetics:
This proposal would make a minor improvement in aesthetics.
Discussion:
This is obviously a low-priority issue, but would require such little
resources to fix that it seems worth doing.
Pitman supports this addition.
It's perhaps too bad that keywords like :SHORT, :MEDIUM, and :LONG
weren't chosen instead of T and NIL, since T and NIL have a bit of a
binary feel to them and it's hard to think of a good name for the
default case.
∂08-Oct-88 2153 X3J13-mailer Issue: SETF-SUB-METHODS (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:53:35 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 21:50:04 PDT
Date: 8 Oct 88 21:50 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: SETF-SUB-METHODS (Version 5)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-215004-2565@Xerox>
!
Issue: SETF-SUB-METHODS
References: CLtL pp. 95-96, 99, 105-106, 166
Issue: PUSH-EVALUATION-ORDER
Category: CLARIFICATION
Edit history: Version 1: JonL White & Ken D. Olum 12-Feb-88
(based on problem originally called SETF-METHOD-FOR-SYMBOLS)
Version 2: JonL White 23-May-88 (fix references and spellings).
Version 3: JonL White 25-May-88
Version 4: JonL White & Ken D. Olum 26-May-88 (final insights!)
Version 5: Masinter (respond to comments)
Problem description:
Implementations differ in the left-to-right order
of evaluation in the following form:
(setq r '(a 1 b 2 c 3))
(setq s r)
(setf (getf r 'b) (progn (setq r nil) 6))
In some implementations, the side-effect of the setq appears to happen before
the evaluation of the place form (getf r 'b) which is necessary to fetch the
list being updated. A typical result is 'r' = (B 6), 's' = (A 1 B 2 C 3)
after the operation.
There is a similar problem with SETF's over LDB, MASK-FIELD, and CHAR-BIT.
CLtL p99 is explicit about left-to-right order of evaluation.
However, the specification is less clear about computations involved
in "evaluation" of the subforms, and other computations that are implicit
in the notion of "doing an access" or "doing a store".
Proposal: SETF-SUB-METHODS:DELAYED-ACCESS-STORES
This proposal specifies more explicilty the behavior of SETF in the case
of access forms whose sub-forms are permitted to be generalized variable
references [and which thus need to call GET-SETF-METHOD during setf macro
expansion].
Remember, first, that GET-SETF-METHOD returns the following:
-- Some temporary variables
-- A list of value-producing forms
-- A list of store-variables (normally one).
-- A storing form.
-- An accessing form.
The code produced as the macro expansion of a SETF form that
itself admits a generalized variable as an argument must essentially
do the following major steps:
** It evaluates the value-producing sub-forms, in left-to-right order, and
binds the temporary variables to them. This will be called "binding the
temporaries."
** It "reads the value" from the generalized variable using the supplied
accessing form, to get the "old value"; this will be called "doing the
access." [Note that this is done after all the evaluations of the
preceeding step, including any side-effects they may have.]
** It binds the store-variable to a new value, and then installs this
new value into the generalized variable using the supplied "storing
form". This will be called "doing the store."
"Reading the value" of a generalized variable reference is not part of
the series of evaluations that must be done in left-to-right order.
The place-specifier forms listed at the top of CLtL p96 permit admit (other)
place-specifiers as arguments; during the SETF expansion of these forms, it
is necessary to call GET-SETF-METHOD in order to figure out how the inner,
nested generalized variable must be treated. This proposal requires GETF be
listed among these forms, since it must have a sub-recursive <place> specifier
[however, there is no Common Lisp function serving as a pseudo-update function
for it, the way DPB serves for LDB].
For each place-specifier form with a sub-recursive place specifier,
the information from GET-SETF-METHOD is used as follows.
CHAR-BIT:
In a form such as:
(SETF (CHAR-BIT <place-form> <bit-name>) <value-form>)
the place referred to by the <place-form> must always be both accessed
and updated; note that the update is to the generalized variable
specified by <place-form> -- not to a character object itself.
Thus this SETF should generate code to do the following:
1. Bind the temporaries for <place-form>
2. Evaluate <bit-name> (and bind into a temporary)
3. Evaluate <value-form> (and bind into the store variable)
4. Do the access to <place-form>
5. Do the store into <place-form>, with the given bit-name of the
character fetched in step 4 changed to reflect the value from step 3.
If the evaluation of <value-form> in step 3 alters what is found in the
given "place" -- such as setting a different "bit" of the character --
then the change of the bit denoted by <bit-name> will be to that altered
character, because the "access" step is done after the <value-form>
evaluation. See example 1 in the test cases section. Nevertheless, the
evaluations required for binding the temporaries are done in steps 1 and
2, and thus the expected left-to-right evaluation order is seen.
LDB:
In a form such as:
(SETF (LDB <byte-spec> <place-form>) <value-form>)
the place referred to by the <place-form> must always be both accessed
and updated; note that the update is to the generalized variable
specified by <place-form> -- not to any object of type integer.
Thus this SETF should generate code to do the following:
1. Evaluate <byte-spec> (and bind into a temporary)
2. Bind the temporaries for <place-form>
3. Evaluate <value-form> (and bind into the store variable)
4. Do the access to <place-form>
5. Do the store into <place-form> with the given bit-field of the integer
fetched in step 4 replaced with the value from step 3.
If the evaluation of <value-form> in step 3 alters what is found in the
given "place" -- such as setting a different bit-field of the integer --
then the change of the bit-field denoted by <byte-spec> will be to that
altered integer, because the "access" step is done after the <value-form>
evaluation. See example 2 in the test cases section. Nevertheless, the
evaluations required for binding the temporaries are done in steps 1 and
2, and thus the expected left-to-right evaluation order is seen.
MASK-FIELD:
This case is the same as LDB in all essential aspects.
GETF:
In a form such as:
(SETF (GETF <place-form> <ind-form>) <value-form>)
the place referred to by the <place-form> must always be both accessed
and updated; note that the update is to the generalized variable
specified by <place-form> -- not necessarily to the particular list
which is the property list in question.
Thus this SETF should generate code to do the following:
1. Bind the temporaries for <place-form>
2. Evaluate <ind-form> (and bind into a temporary)
3. Evaluate the <value-form> (and bind into the store variable)
4. Do the access to <place-form>
5. Do the store into <place-form> with a possibly-new property list
obtained by combining the values from steps 2, 3, and 4.
If the evaluation of <value-form> in step 3 alters what is found in the
given "place" -- such as setting a different named property in the list,
then the change of the property denoted by <ind-form> will be to that
altered list, because the "access" step is done after the <value-form>
evaluation. See example 7 in the test cases section. Nevertheless, the
evaluations required for binding the temporaries are done in steps 1 and
2, and thus the expected left-to-right evaluation order is seen.
Note that this phrase "possibly-new property list" treats the
implementation of property lists as a "black box" -- it can mean that
the former property list is somehow destructively re-used, or it can
mean partial or full copying of it. This is like the question of REMOVE
or DELETE -- do you copy or do you destructively alter. Since the answer
could go either way, the treatment of the resultant value for the
"possibly-new property list" must proceed as if it were a different copy
needing to be stored back into the generalized variable.
The "read-modify-write" macros such as INCF, DECF, PUSH, POP,
and REMF, as well as PSETF, SHIFTF, and ROTATEF should be
specified to have the same evalauation order for the subforms of
the "place" arguments; this would generally follow from their definition
in terms of SETF.
Test Cases:
1. (setq char (make-char #\A 1)) ==> #\Control-A
(rotatef (char-bit char :control)
(char-bit char :meta))
char ==> #\Meta-A
;; It's as if you start with #\Control-A, and then first turn the
;; :control bit off, because the :meta bit was originally off; and
;; then to the resulting #\A, you add the :meta bit since the
;; :control bit was originally on.
Note, however, that if an implementation doesn't support both of these
character 'bits', then this test case would have to be re-written to
reference two independent bits actually supported. If an implementation
supports fewer than two independent character bits, then this test case
is entirely moot.
2. (setq integer #x69) ==> #x69
(rotatef (ldb (byte 4 4) integer)
(ldb (byte 4 0) integer))
integer ==> #x96
;; This very-realistic example is simply trying to swap two
;; independent bit fields in an integer. Note that the generalized
;; variable of interest here is just the (possibly local) program
;; variable 'integer'.
3a.(setq l1 (setq l2 (list #x69))) ==> (#x69)
(setf (ldb (byte 4 4) (car l1))
(ldb (byte 4 0) (car (prog1 l1
(setq l1 nil)))))
l1 ==> nil
l2 ==> (#x99)
;; Note that the (setq l1 nil) didn't affect the actions of the setf
;; at all, since l1 was evaluated and its value was saved away in a
;; temporary variable as part of the step "2. Bind the temporaries
;; for <place-form>", and this was done before the evaluation of the
;; <value-form> which contains the (setq l1 nil). Note also that the
;; step "4. Do the access to <place-form>" means fetching the CAR of
;; the saved (temporary) value of 'l1'; it does not mean doing a LDB
;; on anything like that.
3b.(setq l1 (setq l2 (list #x69))) ==> (#x69)
(setf (ldb (byte 4 4) (car l1))
(ldb (byte 4 0) (car (rplaca l1 #x17))))
l1 ==> (#x77)
l2 ==> (#x77)
;; Note that the (rplaca l1 #x17) altered the contents of what l1
;; was pointing to. Thus even though l1 was evaluated and its
;; value was saved away in a temporary variable as part of the step
;; "2. Bind the temporaries for <place-form>", and even though this
;; was done before the evaluation of the <value-form> which contains
;; the rplaca, still the side-effect changes things because it alters
;; what will be fetched during the "do the access" step.
4. (setq integer #x69)
(setf (mask-field (byte 4 4) integer) (incf integer)) => #x6A
integer ==> #x6A
5. (setq integer #x6A)
(setf (mask-field (byte 4 4) integer) (ash (incf integer) 4)) => #x6B0
integer => #xBB
6. (setq s (setq r (list 'a 1 'b 2 'c 3))) ==> (a 1 b 2 c 3)
(setf (getf r 'b)
(progn (setq r nil) 6)) ==> 6
r ==> (b 6)
s ==> (a 1 b 2 c 3)
;; Note that the generalized variable of concern here is the (degenerate?)
;; one of simply the program variable 'r'; it is not a property-list
;; slot denoted by (getf r 'b). At the time the step "4. Do the access
;; to <place-form>" is performed, the evaluation of the <value-form>
;; has already altered the generalized variable 'r', and thus a nil is
;; returned for this access; that is why a fresh property-list (B 6) is
;; created an stored back into 'r'.
7. (setq s (setq r (list (list 'a 1 'b 2 'c 3)))) ==> ((a 1 b 2 c 3))
(setf (getf (car r) 'b)
(progn (setq r nil) 6)) ==> 6
r ==> nil
s ==> ((A 1 B 6 C 3))
;; Note that the (setq r nil) does not affect the actions of the setf
;; because the value of R had already been saved in a temporary variable
;; as part of the step "1. Bind the temporaries for <place-form>". Only
;; the CAR of this value will be accessed, and subsequently modified
;; after the value computation.
Rationale:
As a principle,
(setf (foo-a x) (progn (setf (foo-b x) ...)
new-a-value))
should always set both of the "slots" of 'x', even if these slots are
implemented as bit-fields, getf-properties, and so on. Only by separating
out evaluation from "generalized variable access", and by specifying that
the access is done after all the evaluations, can this correctly be done.
Current Practice:
Lucid Common Lisp already operates pretty much according to this proposal.
Symbolics Genera 7.2 foolishly adopted an earlier proposal
(SETF-METHOD-FOR-SYMBOLS) before it was officially approved by X3J13 and
its parent standards organization. This proposal is incompatible with
that one, so Genera 7.2 does not implement the behavior described here,
and fails test cases 1, 2, 4, 5, and 6. Symbolics Genera 7.1
is probably closer to this proposal.
Performance impact:
Small. This proposal might slow down macro-expansion slightly,
might cause some current optimizations not to work as well. However,
the net effect is likely negligible.
Cost to Implementors:
In some implementations, this would require a careful revisiting of
the handling of SETF and generalized variable modifiers.
Cost to Users:
Small; although this will impose an incompatible change on
implementations that don't behave as proposed, and might have
an effect on (non-portable) code, we believe the effects
are not widespread.
Cost of non-adoption:
SETF left-to-right order of evaluation will not be well specified;
implementations will differ for no good reason.
Benefits:
Uniform semantics and portability in the face of recursive "place specifiers"
for SETF. Setf of (LDB ... <place>) and of (GETF <place> ...) will behave
uniformly no matter the nature of the <place>.
Anyone who has copied examples from p105 and p106 will continue to
be able to use them.
Esthetics:
See "Cost of non-adoption"
Discussion:
This is a difficult proposal to specify.
In the detailed descriptions for each access form, the phrase
"the place referred to by the <place-form> must always be both
accessed and updated; note that the update is to the generalized
variable specified by <place-form>"
is not intended to prevent optimizations that could occur when the
code "knows" that the new value will be EQ to the old one. The only
requirements is that the results be semantically equivalent.
There is an interesting parallel between this case for GETF and the
very common mistake made by Lisp programmers with respect to the
function DELETE. How often the complaint is filed that DELETE didn't
do anything when it should have; but in fact the filer simply forgot
that delete, although permitted to destructively modify the original
list, may also return some tail of the list originally give it,
whether or not an alteration occurs.
(setq l '(a a b c d)) ==> (a a b c d)
(delete 'a l) ==> (b c d)
l ==> (a a b c d)
The unwary user thinks that because 'l' is still EQ to the original value
that "DELETE didn't do anything". The temptation to ignore the resultant
value of DELETE parallels the temptation to forget about a need to perform
a final update to <place-form> in the setf-of-getf case.
In the (degenerate?) case when a generalized variable
is in fact simply a program variable, then there are no sub-forms to be
considered "value-producing" forms; in fact, "doing the access" for such
a generalized variable (i.e. a program variable) is functionally the
same as evaluating it. This explains why the behaviour in the "Problem
Description" is at first perplexing -- the "do the access" step has the same
semantics as an evaluation step, even though it is done after all the
prescribed evaluations.
The issue PUSH-EVALUATION-ORDER is a clarification about just the point
of the evaluation order for the various subforms to a PUSH; thus there
is a similarity to this issue, but the present issue has a much deeper
problem because of the need to call GET-SETF-METHOD during setf macro
expansion.
∂08-Oct-88 2203 X3J13-mailer DRAFT Issue SYMBOL-MACROLET-SEMANTICS, Version 4
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 22:03:32 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 22:00:34 PDT
Date: 8 Oct 88 22:00 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue SYMBOL-MACROLET-SEMANTICS, Version 4
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-220034-2580@Xerox>
This is DRAFT because of some confusion over the handling
of SETQ of symbol-macros.
!
Issue: SYMBOL-MACROLET-SEMANTICS
References: X3J13 document 88-002R, Chapter 2, pp. 2-81f.
Category: CHANGE
Edit history: 29-July-88, Version 1 by Piazza
21-September-88, Version 2 by Piazza
22-September-88, Version 3 by Piazza
22-September-88, Version 4 by Piazza
Problem Description:
The SYMBOL-MACROLET construct, introduced with CLOS in X3J13 document
88-002R, profoundly alters the interpretation of symbols appearing as
forms in a Common Lisp program--what previously was necessarily a variable
might now be a symbol macro instead. Macros which appear in the body of a
SYMBOL-MACROLET form are currently unable to determine whether a symbol
form is a variable or a symbol macro, and, if the latter, what the
expansion of the symbol macro is. Consequently, complex macros (such as
SETF or PUSH) which depend on the form of their argument(s), are unable to
produce their desired results in some cases, as in the following example:
(let ((a (make-array 5))
(i 0))
(symbol-macrolet ((place (aref a (incf i))))
(push x place))
i) ==> 2
Proposal (SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM):
Change the definition of SYMBOL-MACROLET to specify that it is a special
form, which affects the evaluation environment for symbols. Enhance
MACROEXPAND and MACROEXPAND-1 so that they can expand a symbol macro.
Modify SETF et al to use the new MACROEXPAND and MACROEXPAND-1 to examine
even symbol subforms. Specify that the expansion of a symbol macro IS
subject to further macro expansion in the same lexical environment as the
symbol macro invocation, exactly analogous to normal macros.
Rationale:
The potential for interaction between macros is exactly why &environment
arguments were originally added to macros. Changing SYMBOL-MACROLET to be
a special form, which communicates through the &environment arguments to
macros with MACROEXPAND and MACROEXPAND-1, would allow PUSH and SETF
(among others) to work with SYMBOL-MACROLET in the same way they work with
MACROLET.
This change cannot (reasonably) support the currently specified semantics
that the expansion text is "outside" the scope of the symbol macro. For
indeed, when the symbol macro is expanded, (a copy of) the expansion is
then within the scope of the SYMBOL-MACROLET, and should then be subject
to further scrutiny. The issue of "infinite expansion" of symbol macros is
no more dangerous than that of normal macros.
Current Practice:
Portable Common Loops provides a code-walking implementation of
SYMBOL-MACROLET as specified in 88-002R. Symbolics Cloe has both a
code-walking version of a SYMBOL-MACROLET macro and compiler support for
a SYMBOL-MACROLET special form.
Cost to Implementors:
If SYMBOL-MACROLET is modified to be a special form, compilers and
interpreters will have to change, as well as MACROEXPAND, MACROEXPAND-1,
PUSH, INCF, DECF, and others.
Cost to Users:
If SYMBOL-MACROLET is converted to a special form, code-walking programs
will have to be modified to handle SYMBOL-MACROLET correctly. Those same
programs would have to be modified to handle the other special forms
specified in CLOS, anyway.
Cost of Non-Adoption:
SYMBOL-MACROLET will retain its confusing semantics, leading to bugs when
it interacts with complex macros and forms which produce side-effects.
Implementations which support ONCE-ONLY will break. For that matter, any
mechanism which examines code and assumes that "variables" have no side
effects will break.
Benefits:
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM avoids the hairiest problems
surrounding interaction of macros (like SETF) and side effects, and makes
SYMBOL-MACROLET consistent with MACROLET.
Aesthetics:
If SYMBOL-MACROLET is made to be a special form, aesthetics are improved
by making symbol macros consistent with normal macros.
Discussion:
A case could be made for adding a new function, SYMBOL-MACRO-FUNCTION, as
a dual of MACRO-FUNCTION. However, symbol macros are simpler than normal
macros: a symbol macro is associated with a single expansion form, rather
than an arbitrary function which computes the expansion. For this reason,
the augmented MACROEXPAND-1 proposed here can also fill the role of
SYMBOL-MACRO-FUNCTION: the second value of (macroexpand-1 sym env) will be
T if and only if sym is a symbol macro, while the first value gives the
expansion of sym, if it has one.
Also, Pitman points out that, rather than extending the existing
MACROEXPAND and MACROEXPAND-1 functions, new functions could be introduced
to expand symbol macros. However, there seems to be no particular reason
to do this.
----- End Forwarded Messages -----
∂08-Oct-88 2159 X3J13-mailer DRAFT Issue: STREAM-INFO (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:59:37 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 21:55:17 PDT
Date: 8 Oct 88 21:55 PDT
From: masinter.pa@Xerox.COM
Subject: DRAFT Issue: STREAM-INFO (Version 5)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-215517-2573@Xerox>
This issue has some interactions with the character proposal.
There has been a recommendation (from me) that the functions
be allowed to return/accept non-complex numbers rather than
integers where possible, given the possibilities of output
streams that can do arbitrary scaling.
Perhaps this issue should have been called
PRETTY-PRINT-WIDTH-SUPPORT
!
Status: DRAFT
Issue: STREAM-INFO
References: FORMAT ~T (pp398-9) and ~<...~> (pp404-6), PPRINT (p383)
Category: ADDITION
Edit history: 22-Jun-88, Version 1 by Pitman (2d model)
23-Jun-88, Version 2 by Waters (1d model, modified 2d model)
24-Jun-88, Version 3 by Pitman (minor reformatting)
24-Jun-88, Version 4 by Pitman (remove 2d model for submission)
23-Sep-88, Version 5 by Waters (cleaned up in response to discussion)
Problem Description:
Currently, there is no portable way to inquire about the line width of
an output stream, the current position on a line, or the amount of
space that the display of a string will take up. This makes it
essentially impossible to write a portable implementation of a pretty
printer.
Proposal (STREAM-INFO: ONE-DIMENSIONAL-FUNCTIONS):
Introduce four new functions.
These functions are carefully designed with an eye to the way they
interact. As a result, they can only be defined fully in terms of
each other. The presentation below first gives a very brief
definition of each function and then gives detailed specifications of
their relationships.
LINE-WIDTH &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [Function]
Returns a non-negative integer representing the line width available
when printing to OUTPUT-STREAM. If the stream has no meaningful
width (or the width cannot be computed) then NIL is returned.
LINE-POSITION &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [Function]
Returns a non-negative integer representing the current horizontal
position on the current output line, or NIL if the position cannot
be computed.
WRITE-SPACE WIDTH &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [function]
Inserts blank space of length WIDTH into OUTPUT-STREAM. WIDTH must
be a non-negative integer. WRITE-SPACE returns T if the operation
is successful and NIL otherwise (e.g., if the operation is not
supported by OUTPUT-STREAM).
PRINTED-WIDTH STRING &optional (OUTPUT-STREAM *STANDARD-OUTPUT*)
&key (START 0) (END NIL) [Function]
Returns an integer representing the horizontal width that would be
required to display STRING if it were written at the current moment
to OUTPUT-STREAM using (WRITE-STRING STRING OUTPUT-STREAM :start
START :end END), or NIL if this width cannot be computed. The width
may be negative (e.g., if STRING contains backspace or newline
characters.)
PRINTED-WIDTH does not return any indication of the vertical
distance required when printing STRING. The START and END
parameters delimit a substring of STRING in the usual manner.
PRINTED-WIDTH never causes any change in the state of OUTPUT-STREAM.
The width returned may well depend on the current state of
OUTPUT-STREAM (e.g., the width of tabs depends on the line position
and the width of characters depends on the font in use.) In all
respects the width is computed based on the current state of the
stream. However, the width returned always assumes that the total
line width is infinite---i.e., does not reflect any wraparound or
truncation which might occur.
-The difficulties of a full specification:
The functions above are intended to solve a specific current problem
in CL. To serve this purpose, they must have reasonably precise
specifications. However, there are several things which make it
desirable to have specifications which allow for significant
variability between implementations. First, current implementations
of CL differ greatly in the way IO is supported, and overly strict
specifications might make things very difficult for certain
implementations. Second, CL places no limits on the kinds of
idiosyncratic characters which can be supported by particular
implementations. Third, while many CL implementations only support
the printing of characters in fixed width fonts, it is desirable to
allow for output streams that support variable width fonts.
Finally, it is desirable to leave room to move for the future.
-Operations on standard characters where the line-width has not yet been exceeded.
To deal with the problems above, a layered specification is
provided. The lowest level specification is given in terms of
constraints between the four functions above. In this lowest level
specification, two key simplifying assumptions are made. First, it
is assumed that at the time the constraint applies, none of the
previous operations on the stream S in question have caused output
to go beyond the physical horizontal limits of the output device on
the output lines relevant to the constraints. I.e., it is assumed
that truncation and or wraparound of the output has not occurred on
these lines. Second, it is assumed that all of the characters
output to the stream on the output lines relevant to the constraints
are standard characters as defined in CLTL pp 20-21. The
non-standard character #\newline may have been used to end one line
and start the next. (Note that standard characters are all simple
characters such as A-Z. Particularly, #\tab, #\backspace,
#\newline, are NOT standard characters.) It is further assumed that
the strings (X and Y) referred to in the constraints consist solely
of standard characters.
Basic properties of LINE-POSITION:
1- For all S, (not (minusp (line-position S)).
2- For all S, (zerop (line-position (progn (terpri S) S))).
3- For all S, If something is at line position N on one line and
something else is at line position N on another line, then the
two things are lined up vertically one under the other.
Defining property of WRITE-SPACE
4- For all N,S, let M = (+ (line-position S) N)
if M <= (line-width S), then
(= (line-position (progn (write-space N S) S)) M)
Defining property of PRINTED-WIDTH
5- For all X,S, let M = (+ (line-position S) (printed-width X))
if 0 <= M <= (line-width S), then
(= (line-position (progn (write-string X S) S)) M)
Basic property of LINE-WIDTH
6- For all N,S, let P = (line-position S)
If (+ P N) <= (line-width S) then
(write-space N S) is guaranteed to output space on the end of
the current line without any truncation of wraparound occurring.
7- For all X,S, let P = (line-position S)
If 0 <= (+ P (printed-width X)) <= (line-width S) then
(write-string X S) is guaranteed to output X on the end of
the current line without any truncation of wraparound occurring.
Additional properties of PRINTED-WIDTH
8- For all X,Y (= (printed-width (concatenate 'string X Y) S)
(+ (printed-width X S) (printed-width Y S)))
9- For all X,Z (= (printed-width X S)
(progn (write-string Z S) (printed-width X S)))
-Support for varying width fonts.
A key motivation behind the functions above is dealing with
arbitrary kinds of output devices and output streams that support
variable width fonts. To provide for this, the properties above
place no absolute constraints on the units used for the width
values. In fact, the units can vary from stream to stream. The
only thing that is required is that for a given stream, the units
must be a constant throughout the life of the stream, and the four
functions above must all operate in terms of the same units. The
units should be chosen to be small enough to represent the minimum
possible difference in the length of two strings and large enough
that it is possible to perform (write-space 1). (I.e., a single
pixel is a logical choice.)
If an output stream only supports a single fixed width font, then
the logical width unit to choose is the width of a single character.
Given this choice, the following is a minimal implementation of the
four functions that meets the requirements above.
LINE-WIDTH returns the maximum number of characters which can be
printed on a single line. LINE-POSITION returns the number of
characters output since the last #\newline (or since the creation of
the stream if no #\newlines have been output). (WRITE-SPACE N S)
outputs N #\space characters. Finally, (PRINTED-LENGTH X S) =
(length X).
-Support for non-standard characters and situations where line width
has been exceeded.
In the main, the properties above can be supported even if the line
width has been exceeded and even when non-standard charactres are
involved. However, characters such as #\tab and #\newline can make
it impossible to support properties 7 and 8. In addition, when the
line width is exceeded, property 3 may not hold. It is hoped that
implementors will make a good faith effort to support the functions
in the full range of situations which can be encountered in their CL
implementations. However, the simple implementation suggested above
will probably provide at least 80% of the benefits intended. As a
result, it is important that people not allow the potential
difficulties of a full implementation deter them from making a
minimal implementation.
-Support for derivative streams.
Intentionally, very little is said about what the width units should
be or exactly what LINE-WIDTH should return. The only key criterion
is that LINE-WIDTH should return a result that is pessimistic enough
to ensure proper printing. However, it is useful to make some
comments about these matters with regard to certain types of
derivative streams.
If a synonym stream, two way stream, or echo stream is created, it should
have the same line-width and width unit as the base output stream.
A string output stream should have a line-width of NIL and probably
should be treated as supporting a fixed width font and having an
output width unit so that each character has a printed-width of 1.
If a broadcast stream is created, then LINE-LENGTH, LINE-POSITION,
and PRINTED-WIDTH should be be supported by reflecting them through
to the FIRST base stream. (There is no guarantee that anything
reasonable can be done with the streams as a set. For example, one
might support a varying length font while the others don't.) An
attempt should be made to send WRITE-SPACE requests to all of the
base streams. However, they may not come out right on other than
the first base stream.
Test Case:
Suppose that S is an output stream that supports a single fixed
width font which can display 72 characters on a line and that the
associated width unit is the width of one character. Evaluating the
following will produce the results shown.
(line-width S) => 72
(terpri S) => nil
(output-position S) => 0
(printed-width "testing: " S) => 9
(write-string "testing: " S) => "testing: "
(line-position S) => 9
(write-string "foo" S) => "foo"
(terpri S) => nil
(write-space 9 S) => T
(write-string "bar" S) => "bar"
The output produced is
testing: foo
bar
Rationale:
Pretty printing requires the function LINE-WIDTH to know how wide the
output it produces can be. Pretty printing requires LINE-POSITION to
determine where on the line output is when pretty printing starts.
Pretty printing requires PRINTED-WIDTH to determine how much space
things will take in the output. (If a variable width font is being
used, this cannot be determined without a detailed knowledge of the
font being used.) (Properties 7 & 8 greatly reduce the number of
times PRINTED-WIDTH has to be called.) Pretty printing requires
WRITE-SPACE to get proper indentations. (If a variable width font is
being used, indentations may be required that cannot be obtained by
outputting spaces.)
Current Practice:
Essentially every implementation of Common Lisp must support the
minimal functionality above internally in order to support PPRINT and
the FORMAT directives ~T and ~<...~>. However, there is no documented
interface to this functionality in CLTL. As a result, while some
implementations of Common Lisp make this functionality available to
users, some do not. Further, the implementations that do provide
this functionality do so in a variety of incompatible ways.
Cost to Implementors:
This proposal is written in such a way as to allow implementations
which do not have the ability to compute difficult values to just
return NIL. Very little work is forced. The idea is to offer
implementors a common way to provide this useful information to
portable programs where possible.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Complex output programs such as pretty printers cannot be written portably.
Benefits:
A wide range of programs can gain better control of the format of output.
Aesthetics:
No significant aesthetic impact other than a slight increase in the
number of functions defined.
Discussion:
Dick Waters submitted a request for changes along the line of the
horizontal aspects of these functions in a letter to X3J13 dated
June 14, 1988. Pitman and Waters wrote up the request formally.
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS is the minimum which is
required to support pretty printing into a stream which
displays output using a variable width font.
We drafted an alternate proposal, STREAM-INFO:TWO-DIMENSIONAL-FUNCTIONS,
which goes significantly beyond what is needed merely for pretty printing
and provides primitives LINE-DIMENSIONS, LINE-POSITION,
PRINTED-DIMENSIONS, and WRITE-SPACE but it is not included here.
A key point of contention which would be likely to swamp the 2d proposal
is the age old question of how to handle the issue of vertical distance
(where is the origin, which way do you count, ...). If anyone would
prefer to see larger problem 2d proposal, it could be circulated, but at
the last minute Pitman got worried that even the 1d version was going to
be controversial enough and decided to keep things focused on that.
For his own needs, Waters is strongly interested in having either
ONE-DIMENSIONAL-FUNCTIONS or TWO-DIMENSIONAL-FUNCTIONS proposal accepted,
but does not care which. Pitman concurs.
One variation of the 1d proposal might be useful to consider:
PRINTED-WIDTH could return two additional values: the number of newlines
that WRITE-STRING of the string would execute and the maximum X position
encountered (which might differ from the first value if the number of
newlines was non-zero).
This feature wasn't necessary for Waters' minimalist proposal, but Pitman
would be willing to write it in here if people thought it would be useful
enough for other purposes.
The 5th version was changed from the 4th by responding to suggestions
about better names for the functions, including a discussion of how
line-width should apply to various kinds of derivative streams, and
most importantly, by including a much more precise specification for
what the minimal capabilities of the functions should be.
----- End Forwarded Messages -----
∂08-Oct-88 2159 X3J13-mailer DRAFT Issue: SYMBOL-MACROLET-DECLARE (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:59:47 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 21:58:06 PDT
Date: 8 Oct 88 21:58 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: SYMBOL-MACROLET-DECLARE (version 1)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-215806-2579@Xerox>
!
Issue: SYMBOL-MACROLET-DECLARE
References: SYMBOL-MACROLET (88-002R page 2-81)
WITH-ACCESSORS (88-002R page 2-88)
WITH-SLOTS (88-002R page 2-92)
Category: ADDITION
Edit history: Version 1, 12-Sep-88, Moon
Problem description:
It would be both natural and nice to be able to write
(with-slots (rho theta) point
(declare (single-float rho theta))
...computation...)
Proposal (SYMBOL-MACROLET-DECLARE:ALLOW):
Allow declarations at the head of the body of SYMBOL-MACROLET, and hence
in WITH-ACCESSORS and WITH-SLOTS. Exactly the same declarations are
allowed as for LET, with one exception: SYMBOL-MACROLET signals an error
if a SPECIAL declaration names one of the symbols being defined as a
symbol-macrolet. A type declaration of one of these symbols is equivalent
to wrapping a THE expression around the expansion of that symbol.
Test Cases/Examples:
See problem description.
Rationale:
If SYMBOL-MACROLET is intended to resemble LET in syntax, it ought to
allow declarations. When writing a SYMBOL-MACROLET directly, the user
could just as easily write a THE expression instead of a type
declaration. However, when invoking a macro such as WITH-SLOTS that
expands into SYMBOL-MACROLET, the user does not have this option since
the expansion is not supplied explicitly by the user.
Current practice:
SYMBOL-MACROLET was only tentatively added to Common Lisp 3 months ago.
Cost to Implementors:
Less than one man-hour.
Cost to Users:
None.
Cost of non-adoption:
Minor wart in the language.
Benefits:
More consistent language definition.
Esthetics:
More consistent language definition.
Discussion:
None.
----- End Forwarded Messages -----
∂08-Oct-88 2211 X3J13-mailer DRAFT Issue: TEST-NOT-IF-NOT (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 22:11:20 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 22:07:11 PDT
Date: 8 Oct 88 22:07 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: TEST-NOT-IF-NOT (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-220711-2583@Xerox>
!
Issue: TEST-NOT-IF-NOT
References: Functions offering a :TEST-NOT keyword:
ADJOIN (p276), ASSOC (p280), COUNT (p257), DELETE (p254),
DELETE-DUPLICATES (p254), FIND (p257),
INTERSECTION (p277), MEMBER (p275), MISMATCH (p257),
NINTERSECTION (p277), NSET-DIFFERENCE (p278),
NSET-EXCLUSIVE-OR (p278), NSUBLIS (p275), NSUBST (p274),
NSUBSTITUTE (p256), NUNION (p276), POSITION (p257),
RASSOC (p281), REMOVE (p253), REMOVE-DUPLICATES (p254),
SEARCH (p258), SET-DIFFERENCE (p278),
SET-EXCLUSIVE-OR (p278), SUBLIS (p274), SUBSETP (p279),
SUBST (p273), SUBSTITUTE (p255), TREE-EQUAL (p264),
UNION (p276);
Functions with "-IF-NOT" in their name:
ASSOC-IF-NOT (p280), COUNT-IF-NOT (p257),
DELETE-IF-NOT (p254), FIND-IF-NOT (p257),
MEMBER-IF-NOT (p275), NSUBST-IF-NOT (p274),
NSUBSTITUTE-IF-NOT (p256), POSITION-IF-NOT (p257),
RASSOC-IF-NOT (p281), REMOVE-IF-NOT (p253),
SUBST-IF-NOT (p273), SUBSTITUTE-IF-NOT (p255);
Issue FUNCTION-COMPOSITION
Category: CHANGE
Edit history: 02-Oct-88, Version 1 by Pitman (just FLUSH-ALL)
05-Oct-88, Version 2 by Pitman (add option FLUSH-TEST-NOT)
Status: For Internal Discussion
Problem Description:
The -IF-NOT functions are functionally unnecessary.
The :TEST-NOT keywords are not only functionally unnecessary but
also problematic because it's not clear what to do when both :TEST
and :TEST-NOT are provided.
Many people think Common Lisp is more `bloated' than it needs
to be and these aspects of the language are commonly cited
specific examples.
Proposal (TEST-NOT-IF-NOT:FLUSH-ALL):
Remove all -IF-NOT functions (named above) from Common Lisp.
Remove the :TEST-NOT keyword from the Common Lisp functions which
currently provide them (named above).
Rationale:
This makes the language a bit simpler.
The removal of :TEST-NOT also makes the language easier to explain.
Cost to Implementors:
Very slight.
Some symbols would disappear from the LISP package but could
still be offered in proprietary packages if deemed important
enough.
Implementations could compatibly retain the :TEST-NOT keywords
for an interim period.
Proposal (TEST-NOT-IF-NOT:FLUSH-TEST-NOT):
Remove the :TEST-NOT keyword from the Common Lisp functions which
currently provide them (named above).
Rationale:
This makes the language a bit simpler and easier to explain.
Cost to Implementors:
Very slight.
Implementations could compatibly retain the :TEST-NOT keywords
for an interim period.
Current Practice:
Presumably no one has done this yet.
Cost to Users:
Some rewrites would be needed.
Those rewrites, which are already fairly simple, would be even
more simple if some form of the FUNCTION-COMPOSITION issue is
voted in -- in particular, the COMPLEMENT function which it
proposes would help enormously in this regard.
Cost of Non-Adoption:
Common Lisp would continue to be what some people feel is
"bigger than it needs to be".
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
Presumably this makes the language easier to teach.
Discussion:
Moon expressed reservations about FLUSH-ALL (in Version 1, where
FLUSH-TEST-NOT was not offered) because it was such an incompatible
change.
Steele (commenting on Version 1) noted that his main reservation to
FLUSH-ALL is that he uses REMOVE-IF-NOT much more than REMOVE-IF.
Pierson, Dalton and Pitman support the combination of
TEST-NOT-IF-NOT:FLUSH-ALL (and FUNCTION-COMPOSITION:NEW-FUNCTIONS)
in spite of the incompatible change because of the aesthetic appeal.
This issue is related to FUNCTION-COMPOSITION, but is not dependent
on it.
van Roggen points out that a long time ago, he suggested dropping
-IF-NOT and :TEST-NOT, adding a function such as COMPLEMENT, and
adding a #~ readmacro such that
(FIND-IF-NOT #'ZEROP '(0 0 3))
== (FIND-IF (COMPLEMENT #'ZEROP) '(0 0 3))
== (FIND-IF #~ZEROP '(0 0 3))
Richard Mlynarik suggests that even the -IF functions provide
little extra use since
(xxx-IF test sequence ...)
can be rewritten
(xxx test sequence :test #'funcall).
He says he doesn't care what we do with this issue, however, since
he will just continue to use [MIT-style] LOOP in cases where these
sequence functions would seem to be called for.
----- End Forwarded Messages -----
∂08-Oct-88 2216 X3J13-mailer DRAFT Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Oct 88 22:16:04 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 473488; Sun 9-Oct-88 01:14:46 EDT
Date: Sun, 9 Oct 88 01:14 EDT
From: CL-Cleanup@SAIL.Stanford.EDU
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: DRAFT Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
To: X3J13@SAIL.Stanford.EDU
cc: cutting.pa@Xerox.COM
References: <880801-102621-1527@Xerox>
Message-ID: <881009011429.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
This is a DRAFT still under discussion. The "Additional Comments"
at the end are still to be dealt with.
-----
Issue: UNREAD-CHAR-AFTER-PEEK-CHAR
References: pp 379, 380 of CLtL
Category: CLARIFICATION
Edit history: Version 1 by Doug Cutting <Cutting.PA@Xerox.COM> on July 29, 1988
Problem description:
PEEK-CHAR and UNREAD-CHAR are very similar mechanisms. The description of
PEEK-CHAR in CLtL even states that "it is as if one had called READ-CHAR and
then UNREAD-CHAR in succession." But while CLtL prohibits calling UNREAD-CHAR
twice in succession it does not prohibit calling UNREAD-CHAR after PEEK-CHAR.
The obvious implementation of PEEK-CHAR and UNREAD-CHAR (a one-character buffer)
will not work unless this prohibition is present.
Proposal (UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW): UNREAD-CHAR may not be called
after PEEK-CHAR without an intervening call to READ-CHAR.
Test Cases/Examples:
;;; Following is an example of code which should not be valid CL.
(defun test (stream)
(let ((char (read-char stream)))
(peek-char nil stream)
(unread-char char stream)
(assert (eql char (read-char stream)))))
Rationale:
PEEK-CHAR and UNREAD-CHAR provide equivalent functionality and it is thus
reasonable for an implementation to implement them in terms of the same
mechanism.
Current practice:
In Xerox Common Lisp, different (non-random-access) stream types behave
differently. One, (TCP/FTP) handled this correctly, while another (keyboard with
line-buffering turned off) did not.
Cost to Implementors:
Zero. Implementations which allow this are still correct.
Cost to Users:
Small. I suspect there is very little code which depends upon this working
correctly, as most code uses either PEEK-CHAR or UNREAD-CHAR, but not both.
Cost of non-adoption:
Implementations of sequential streams are forced to be unnecessarily complex in
order to be correct.
Benefits:
Allows simple yet adequately powerful implementation of sequential streams.
Esthetics:
Requires that users have shared, one-char buffer model of how UNREAD-CHAR and
PEEK-CHAR work, rather than two separate one-char buffers.
Discussion:
- - - - - - - - - - Additional Comments - - - - - - - - - -
- The proposal part is confusingly worded.
The wording says that in a stream "abc", if I READ-CHAR to get the #\a
into variable CH1 and then I PEEK-CHAR to see the "b", then I must call
READ-CHAR before I can (UNREAD-CHAR CH1). But if I take that literally,
I'll do (SETQ CH2 (READ-CHAR S)) (UNREAD-CHAR CH1 S) and that's not what
I want. Having done the READ-CHAR, I can only UNREAD-CHAR the char I just
did READ-CHAR to get. In effect, I can never UNREAD-CHAR CH1 once I've
peeked at or read the next char. Some streams will let me back up at this
point, but only those which would have let me back up before doing the
READ-CHAR in the first place.
It would be clearer for the proposal to just say that doing either a
PEEK-CHAR or READ-CHAR `commits' all previous characters. UNREAD-CHAR
on any character preceding that which is seen by the PEEK-CHAR (including
those passed over by PEEK-CHAR when `seeking' with a non-NIL first
argument) is not portable.
- A misreading of the proposal might lead one to believe that one could
do (SETQ CH1 (READ-CHAR STREAM))
(SETQ CH2 (PEEK-CHAR NIL STREAM))
(SETQ CH3 (READ-CHAR STREAM))
(UNREAD-CHAR CH1 STREAM)
since the unread-char is correctly separated from the PEEK-CHAR by an
intervening READ-CHAR. The problem is that the wrong char is being
unread. Some implementations support this, but it's definitely not
condoned by the description of UNREAD-CHAR on p379.
- I found the following test case to be more insightful:
(defun test (&optional (stream *standard-input*))
(let* ((char1a (read-char stream))
(char2a (peek-char nil stream))
(char1b (progn (unread-char char1a stream)
(read-char stream)))
(char2b (read-char stream)))
(list char1a char2a char1b char2b)))
- Current practice (for my test case above) in Symbolics Genera:
(test)ab
=> (#\a #\b #\a #\b)
(with-input-from-string (s "abc") (test s))
=> (#\a #\b #\a #\b)
(progn (with-open-file (s "foo.output" :direction :output)
(write-string "abc" s))
(with-open-file (s "foo.output" :direction :input)
(test s)))
Signals an error about unreading #\a when #\b was already unread.
∂08-Oct-88 2211 X3J13-mailer DRAFT Issue: TAILP-NIL (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 22:11:11 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 22:07:06 PDT
Date: 8 Oct 88 22:07 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: TAILP-NIL (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-220706-2582@Xerox>
!
Issue: TAILP-NIL
References: TAILP (p275)
Category: CLARIFICATION/CHANGE
Edit History: 13-Sep-88, version 1 by Walter van Roggen,
13-Sep-88, version 2 by Pitman
Problem Description:
CLtL (p275) specifies TAILP as:
TAILP sublist list [Function]
This predicate is true if SUBLIST is a sublist of LIST (i.e.,
one of the conses that makes up LIST); otherwise, it is false.
Another way to look at this is that TAILP is true if
(NTHCDR n list) is SUBLIST, for some value of N. See LDIFF.
Two common implementations of this definition are:
(defun tailp (sublist list) ;Definition "A"
(do ((list list (cdr list)))
((endp list) nil)
(if (eq sublist list)
(return t))))
(defun tailp (sublist list) ;Definition "B"
(do ((list list (cdr list)))
((atom list) (eq list sublist))
(if (eq sublist list)
(return t))))
They differ only in their treatment of the atomic case.
At issue is the fact that () is a list, and hence some would
argue that it is a sublist of all other lists. On the other hand,
the definition of TAILP seems to imply that being a cons is a
necessary precondition of being a "sublist".
Proposal (TAILP-NIL:NIL):
Clarify that the sublist argument to TAILP must be a list
and that (TAILP NIL X) returns NIL for all lists X.
Qualify the description in CLtL by saying that (TAILP sublist list)
is true if SUBLIST is a cons and (NTHCDR n list) is SUBLIST for
some value of N, and is false otherwise.
Rationale:
This is the status quo in a number of implementations.
Proposal (TAILP-NIL:T):
Strike any text in the definition of TAILP which suggests that a
sublist must be a cons.
Clarify that (TAILP any-atom list) returns T iff (NTHCDR n list) is
SUBLIST for some value of N, and false otherwise.
Rationale:
This is more consistent with the definition of LDIFF, which
gives a useful meaning to arbitrary atomic SUBLIST arguments.
This gives a more elegant definition of SUBLIST, allowing it to
refer to any list -- including the empty list -- which is a
part of another list.
Test Cases:
#1: (LET ((X '(B C))) (TAILP X (CONS 'A X)))
should return T in all implementations.
#2: (TAILP '(X Y) '(A B C))
should return NIL in all implementations.
#3: (TAILP '() '(A B C))
returns NIL under proposal TAILP-NIL:NIL
returns T under proposal TAILP-NIL:T
#4: (TAILP 3 '(A B C))
is an error under proposal TAILP-NIL:NIL
returns NIL under proposal TAILP-NIL:T
#5: (TAILP 3 '(A B C . 3))
is an error under proposal TAILP-NIL:NIL
returns T under proposal TAILP-NIL:T
#6: (TAILP '(X Y) '(A B C . 3))
is an error under proposal TAILP-NIL:NIL
returns NIL under proposal TAILP-NIL:T
Current Practice:
Symbolics Genera is consistent with TAILP-NIL:T.
[Walter alleges TAILP-NIL:NIL is what all implementations already
do, but since Genera is not in conformance, KMP regards that
hypothesis as suspect. We need real data points, folks.]
Cost to Implementors:
An implementation of TAILP-NIL:NIL is given as Definition "A" in the
problem description.
An implementation of TAILP-NIL:T is given as Definition "B" in the
problem description.
Some implementations might have compiler optimizers for these definitions
as well, so a slight amount of additional effort might be required.
Cost to Users:
Given that current practice varies widely on the disputed case,
this is unlikely to have a practical effect on existing portable code.
Benefits:
Either description makes the language more precise.
[Pitman believes that] TAILP-NIL:T is more consistent with the behavior
of TAILP and more consistent with what he thinks should be the
definition of a sublist.
Discussion:
This issue was first raised in ">GLS>clarifications.text" of 12/06/85.
Pitman supports TAILP-NIL:T.
----- End Forwarded Messages -----
∂09-Oct-88 0230 X3J13-mailer Draft Issue: CLOS-CONDITIONS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Oct 88 02:30:05 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 473546; Sun 9-Oct-88 05:28:47 EDT
Date: Sun, 9 Oct 88 05:28 EDT
From: CL-ERROR-HANDLING@SAIL.Stanford.EDU
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Draft Issue: CLOS-CONDITIONS (Version 3)
To: X3J13@SAIL.Stanford.EDU
Message-ID: <881009052832.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
There's been some disagreement about a couple of details, so this may
change yet again before we ask you to vote on it, but this is the
version that is likely to be presented for comment at the meeting.
The conflict is represented in the writeup by the presence of two
variant proposals, YES-OPTION-A and YES-OPTION-B.
-----
Issue: CLOS-CONDITIONS
References: Condition System (Revision 18)
Category: ADDITION
Edit history: 26-Sep-88, Version 1 by Pitman
06-Oct-88, Version 2 by Pitman
09-Oct-88, Version 3 by Pitman
Status: For Internal Discussion
Problem Description:
The description of the Common Lisp condition system presupposes
only DEFSTRUCT and not DEFCLASS because it was written when
CLOS had not been adopted. It is stylistically out of step with
CLOS in a few places and places some restrictions which are not
necessary if CLOS can be presupposed.
Subproposal (CLOS-CONDITIONS:YES):
[These options are very similar. They agree except as otherwise noted.]
Define that condition types are CLOS classes.
Define that condition objects are CLOS instances.
Permit multiple parent-types to be named in the list of
parent types. Define that these parent types are treated the
same as the superior class list in a CLOS DEFCLASS expression.
Define that slots in condition objects are normal CLOS slots.
Note that WITH-SLOTS can be used to provide more convenient
access to the slots where slot accessors are undesirable.
Functions such as SIGNAL, which take arguments of class names,
are permitted to take class objects. Such class objects must
still be subclasses of CONDITION.
Eliminate the :CONC-NAME option to DEFINE-CONDITION.
Define that condition reporting is mediated through the
PRINT-OBJECT method for the condition type (class) in question,
with *PRINT-ESCAPE* always being NIL. Specifying
(:REPORT fn) in the definition of a condition type C is
equivalent to doing
(DEFMETHOD PRINT-OBJECT ((X c) STREAM)
(IF *PRINT-ESCAPE* (CALL-NEXT-METHOD) (fn X STREAM)))
Proposal (CLOS-CONDITIONS:YES-OPTION-A):
All of subproposal YES, plus the following...
Extend the syntax for a slot in a DEFINE-CONDITION as follows...
- If a symbol is used, DEFINE-CONDITION will by special case
treat this as if (symbol :INITARG keyword :READER reader-name)
were specified instead, where KEYWORD is generated by
(INTERN (SYMBOL-NAME symbol) (FIND-PACKAGE "KEYWORD"))
and reader-name is generated by
(INTERN (FORMAT NIL "~A-~A" condition-type symbol))
for CONDITION-TYPE being the condition type being defined.
- A length 1 list, (symbol), is treated the same as providing
the symbol itself.
- If a length 2 list, (symbol value) is provided, it is treated
as (symbol :INITARG keyword :READER reader-name :INITFORM value),
with KEYWORD and READER-NAME being computed as above.
- If a list of length greater than 2 is used, it is treated
the same as a CLOS slot-specifier. In that case, the :INITARG
and :READER options must be explicitly specified if desired.
This syntax is compatible with the existing semantics of
DEFINE-CONDITION.
Rationale:
This provides maximal compatibilty with the old semantics
for DEFINE-CONDITION, which numerous vendors now distribute.
Further, and perhaps more importantly, the uses of slots in
DEFINE-CONDITION are highly constrained. They are not assigned
so an INITARG is nearly always needed. There are almost
universally accessed externally, so a :READER is usually
needed. This syntax makes what is by far the most convenient
use very syntactically simple.
Proposal (CLOS-CONDITIONS:YES-OPTION-B):
Incompatibly change the syntax of a slot in DEFINE-CONDITION
to be compatible with a DEFCLASS slot specification.
An implication of this change is that forms like
(DEFINE-CONDITION FOO (BAR) ((A 1) (B 2)))
would have to be written
(DEFINE-CONDITION FOO (BAR) ((A :INITARG :A :READER FOO-A :INITFORM 1)
(B :INITARG :B :READER FOO-B :INITFORM 2)))
Rationale: This is most compatible with CLOS.
Examples:
Slot specifiers...
Under YES-OPTION-A ...
A slot specifier of X in condition type FOO is still valid
and means the same as (X :INITARG :X :READER FOO-X).
A slot specifier of (X) in condition type FOO is still valid
and means the same as (X :INITARG :X :READER FOO-X).
A slot specifier of (X V) in condition type FOO is still
valid and means the same as
(X :INITARG :X :READER FOO-X :INITFORM V).
In addition, other slot specifiers such as
(X :INITARG :EX :TYPE FIXNUM)
are permitted as in DEFCLASS.
Under YES-OPTION-B ...
A slot specifier of X is still valid but is incompatibly
changed to mean what CLOS has it mean; no :INITARG or
:READER would be supplied.
A slot specifier of (X) is still valid but is incompatibly
changed to mean what CLOS has it mean; no :INITARG or
:READER would be supplied.
A slot specifier of (X V) would no longer be valid.
In addition, other slot specifiers such as
(X :INITARG :EX :TYPE FIXNUM)
are permitted as in DEFCLASS.
Conc names ...
(DEFINE-CONDITION FOOBAR (FOO BAR) (X Y) (:CONC-NAME FUBAR))
would be rewritten
(DEFINE-CONDITION FOOBAR (FOO BAR)
((X :INITARG :X :READER FUBAR-X)
(Y :INITARG :Y :READER FUBAR-Y)))
Report methods ...
(DEFINE-CONDITION OOPS (ERROR) ())
(DEFMETHOD PRINT-OBJECT ((X OOPS) STREAM)
(IF *PRINT-ESCAPE*
(CALL-NEXT-METHOD)
(FORMAT STREAM "Oops! Something went wrong.")))
(ERROR 'OOPS)
>>Error: Oops! Something went wrong.
Rationale:
These changes are consistent with the intent of the recent
X3J13 endorsement of CLOS and the Common Lisp Condition System.
The shorthand notations for DEFINE-CONDITION's slots spec
are justified since the the way in which condition slots are
used is much more highly constrained than for arbitrary classes.
This means we can predict what will be the common case and make
it far more syntactically convenient than it might otherwise be.
Although flushing :CONC-NAME is an incompatible change, nothing
forbids an implementation from supporting it as an extension
during a transition period.
Current Practice:
Some implementations supporting CLOS probably already do this,
or something very similar.
Cost to Implementors:
If you really have CLOS, this is very straightforward.
Cost to Users:
Small, but tractable.
The main potential problems are:
- :CONC-NAME. There is nothing that keeps an implementation from
continuing to support :CONC-NAME for a short while until old code
has been upgraded.
- The incompatible change to slot syntax. Again, it is possible to
unambiguously recognize a 2-list as old-style syntax and an
implementation can provide interim compatibility support during
a transition period.
Even if implementations did not provide the recommended compatibility
support, users could trivially shadow DEFINE-CONDITION and provide the
support themselves, expanding into the native DEFINE-CONDITION in the
proper syntax.
Cost of Non-Adoption:
Conditions will seem harder to manipulate than other user-defined types.
People will wonder if CLOS is really something we're committed to.
Benefits:
A more regular language.
Aesthetics:
Anything that makes the language more regular improves the aesthetics.
Discussion:
People seem to disagree about the status that CLOS might occupy
in the upcoming standard. In spite of a vote of support, they seem
to think it might be optional in some way. Passing this proposal
establishes a clear precedent for the full integration of CLOS into
the emerging language.
Moon suggests that we might want to add condition types for the errors
CLOS might signal. It isn't obvious (to Pitman, at least) that this
change is as straightforward as it looks, though, so it will have to
come up under separate cover.
Richard Mlynarik suggests adding a generic function, REPORT-CONDITION,
which is used for reporting conditions. It is possible to discuss such
a generic function as a separate issue layered atop the substrate which
this proposal provides, so that issue has been deferred.
Pitman supports this change, with mild preference for YES-OPTION-A.
Gregor supports this change, with strong preference for YES-OPTION-B.
∂09-Oct-88 1359 @Score.Stanford.EDU:Mailer@SAIL.Stanford.EDU disk use charges
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Oct 88 13:59:01 PDT
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 9 Oct 88 13:54:49-PDT
Message-ID: <Ooxvd@SAIL.Stanford.EDU>
Date: 09 Oct 88 1357 PDT
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: disk use charges
To: faculty@SCORE.STANFORD.EDU, su-computers@SAIL.Stanford.EDU
Let me explain why I was angry by what I thought was an
increase in SAIL charges for disk use, and why I think the
present charges are bad policy.
1. The charges are way out of line with costs for disk file -
by a factor larger than 10 and perhaps larger than 100. SAIL's
present (somewhat reduced) charges of $2.75 per megabit month
would pay for RAM chips to store the files in two months and for
buying disk units in one month.
2. The rationale of the policy of high disk charges is to get
approximately one third of the income from login time, one third
from compute charges and one third from disk use. From a purely
administrative point of view, this rule of thumb makes as much
sense as any other rule of thumb.
3. It is also true that an individual can assure himself of keeping
down his disk charges by pruning files regularly and by judicious use
of archival computers and tape. Moralists like the idea of rewarding
virtue and punishing sin, and maybe some people imagine that keeping
unnecessary files is just the kind of minor sin that is appropriately
punished by the charge algorithm.
4. So what's wrong with it?
I invented the idea of time-shared computing in 1957 - first
memo January 1959 and first publication 1960. The idea is
that an individual should do his computing at his leisure,
sitting at a terminal in his own office or home and that the
operating system should insure that when he was thinking
the system was fully available to others, and when he was
ready to compute he should get prompt service. Specifically
included in the idea was a feature, first proposed in 1945
by Vannevar Bush in his (non-computer) Memex article, that
a person should keep all his personal files in the machine.
It seemed to me then that this meant that as soon as technology
made it possible, a person should be able to keep a copy of all
he ever wrote permanently on-line as well as all his correspondence
to the extent to which the correspondence was capturable in
computer memory.
By the early 1970s, disk technology had advanced to the point
where this was economically feasible, and I adopted it as a personal policy.
I deviated from it a few times when there was a big delay in
getting new disks at SAIL. I would dearly like to get those
old files back, but at present prices I can't afford even my
present files.
I would like everyone to be able to adopt the same policy of
keeping a permanent record on-line of everything he has ever
typed into a computer.
At present the Computer Science Department doesn't even allow
for keeping technical reports and PhD theses on-line. This
is because disk charge policy is determined by administrative
convenience assisted by a lack of imagination. There are too
many young fogeys in the Department, who, two months after
learning how things are done, imagine that they have been
done this way from eternity and will continue to be done
this way for eternity.
It is of a piece with the fact that the ACM is five to ten
years behind the American Mathematical Society in the use
of computers in publication.
5. Of course, CSD-CF has to recover its costs. These costs
are primarily personnel costs associated with the variety
of computer systems maintained. There is only a tiny
co-efficient directly proportional to the amount of disk
file. A better algorithm is required that will make it
possible and normal to maintain large personal files.
∂10-Oct-88 0813 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Facutly Lunch, Tuesday 10/11/88
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Oct 88 08:13:37 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 10 Oct 88 08:09:06-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA17508; Mon, 10 Oct 88 08:10:27 PDT
Date: Mon, 10 Oct 1988 8:10:25 PDT
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score, spirou@polya.Stanford.EDU,
r.rhino@macbeth, cm.ter@forsythe
Cc: chandler@polya.Stanford.EDU
Subject: Facutly Lunch, Tuesday 10/11/88
Message-Id: <CMM.0.87.592499425.chandler@polya.stanford.edu>
This is to reimind you of the faculty lunch tomorrow. Sally Cole, Stanford's
Judicial Affairs Officer, will be our guest for a discussion of the Stanford
Honor Code and some new procedures Sally is instituting that affect Computer
Science.
See you there!
∂10-Oct-88 1425 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Concurrency '88 -- Final Program
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Oct 88 14:25:25 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA14911; Mon, 10 Oct 88 14:23:39 PDT
Message-Id: <8810102123.AA14911@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 10 Oct 88 14:24:21 PDT
Received: by BYUADMIN (Mailer X1.25) id 5568; Mon, 10 Oct 88 15:20:38 MDT
Date: Mon, 10 Oct 88 16:02:11 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Joe Halpern <halpern@IBM.COM>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Joe Halpern <halpern@IBM.COM>
Subject: Concurrency '88 -- Final Program
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
CONCURRENCY 88
Hamburg, Fed. Rep. of Germany, Oct.λ18.-19., 1988
Final Program
An international conference on Concurrency will be held in
connection with the annual conference of the German Society for
Computer Science. The conference will emphasize the formal methods
for distributed systems. The present great interest in this field
results from expectations that formal methods will be a solution
to the problem of handling the complexity of distributed systems.
Up to now, the various methodological approaches, such as
constructive or constraint-oriented methods, have not had an
extensive comparative analysis, nor have they been investigated
with respect to their possible practical implications.
Particularly in Europe the different methods are considered to be
more or less competitors, and investigations of the possible
integration, combination and unification of the different methods
have been neglected. In the United States, on the other hand, the
discussion and cooperation among representatives of different
methods is considerably more prevalent. Some of the most famous
experts in this field will be presenting their research
experiences during the conference as invited speakers. In detail
the conference addresses the following topics:
- Specification Languages for Concurrent Systems
- Models for Distributed Systems
- Verification and Validation
- Knowledge Based Protocol Modelling
- Faulttolerance
- Distributed Databases
Program Committee:
H. Barringer (University of Manchester)
M. Broy (University of Passau),
D. Hogrefe (University of Hamburg(Org.))
B. Mahr (Technical University Berlin)
G. Roucairol (Bull, Louveciennes)
R. Schwartz (Borland International, Belmont)
R. Valk (University of Hamburg (Vice chair))
F. Vogt (University of Hamburg (Chair))
Welcome F. VOGT, Chairman
Application I (invited), Chair: F. Vogt
While Waiting for the Millennium: Formal Specification and
Verification of Concurrent Systems Now, L. LAMPORT, DEC Systems
Research Center, Palo Alto (U.S.A)
A Framework for the Synthesis of Reactive Modules, A. PNUELI, The
Weizmann Institute of Science, Rehovot (Israel) / Stanford
University, Palo Alto (U.S.A.)
Specification I (invited), Chair: R. Valk
Modelling Knowledge and Action in Distributed Systems, J. HALPERN,
R. FAGIN, IBM Almaden Research Center, San Jose (U.S.A.)
Requirements and Design Specification for Distributed Systems,
M. BROY, University of Passau, (FRG)
Application II (invited), Chair: F. Vogt
Data Base Distribution and Concurrency for End-Users, R. SCHWARTZ,
Borland International, Belmont (U.S.A.)
On Safety and Timeliness in Distributed Data Management, D. DOLEV,
H. R. STRONG,, IBM Almaden Research Center, San Jose (U.S.A.)
Specification II (invited), Chair: R. Valk
An Automata-Theoretic Approach to Protocol Verification, M. VARDI,
IBM Almaden Research Center, San Jose (U.S.A.)
On the Power of Cooperative Concurrency, D. DRUSINSKY, D. HAREL,
The Weizmann Institute of Science, Rehovot (Israel)
Application III, (invited), Chair: F. Vogt
Executing Temporal Logic: Review and Prospects, H. BARRINGER, The
University of Manchester, D. GABBAY, Imperial College, London
(U.K.)
A Graphical Representation of Interval Logic, P. M. MELLIAR-SMITH,
University of California, Santa Barbara (U.S.A)
Specification III, (invited), Chair: R. Valk
Temporal Logic and Causality in Concurrent Systems, W. REISIG,
GMD, St.-Augustin (FRG)
Data in a Concurrent Environment, E. ASTESIANO, A. GIOVINI,
G. REGGIO, University of Genova (Italy)
Specification Languages I, Chair: D. Hogrefe
The Scope and Limits of Synchronous Concurrent Computation,
K. MEINKE, J. V. TUCKER, University of Leeds, (U.K.)
A Logic-Functional Approach to the Execution of CCS Specifications
Modulo Behavioral Equivalence, S. GNESI, P. INVERARDI, M. NESI,
IEI-CNR, Pisa (Italy)
Specification Languages II, Chair: D. Hogrefe
A Top-down Step-wise Refinement Methodology for Protocol
Specifications, D.-H. LI, T. MAIBAUM, Imperial College, London
(U.K.)
A State Transformation Equivalence of Concurrent Systems:
Exhibited Functionality-equivalence, F. DE CINDIO, G. DE MICHELIS,
L. POMELLO, C. ∨SIMONE, University of Milan, (Italy)
External Behaviour Equivalence between two Petri Nets,
A. BOURGUET-ROUGER, CNET, Issy-le-Moulineaux (France)
Models for Distributed Systems I, Chair: B. Mahr
Weighted Basic Petri Nets, E. BEST, GMD, St. Augustin, Schloa
Birlinghofen (FRG)
Total Algorithms, G. TEL, University of Utrecht, (Netherlands)
Model for Distributed Systems II, Chair: M. Broy
Semantics of Real-time Distributed Programs, G. ASIS, M. JOSEPH,
University of Warwick, Coventry (U.K.)
An Example of Communicating Production Systems, B. IGEL,
G. REICHWEIN, University of Dortmund, (FRG)
Verification and Validation I, Chair: G. Roucairol
Assertional Verification of a Majority Consensus Algorithm for
Concurrency Control in Multiple Copy Databases, N. J. DROST,
J. VAN LEEUWEN, University of Utrecht, (Netherlands)
Analysis of ESTELLE Specifications, U. THALMANN, Technical
University Vienna, (Austria)
Verification and Validation II, Chair: G. Roucairol
Optimal Synchronization of ABD Networks, E. KORACH, The Technion,
Haifa, (Israel), G. TEL, University of Utrecht, (Netherlands),
S. ZAKS, The Technion, Haifa, (Israel)
Adequacy-Preserving Transformations of COSY Path Programs,
M. KOUTNY, The University of Newcastle, (U.K.)
Deterministic Systems of Sequential Processes: Theory and Tools,
Y. SOUISSI, Bull Research Laboratory, Louveciennes, N. BELDICEANU,
MASI Laboratory, Paris, (France)
For further information please contact:
Prof. F. Vogt
EAN-Mail: vogt@rz.informatik.uni-hamburg.dbp.de
int. Tel.: + 49 40 4123 6160/6161
∂11-Oct-88 1434 @Score.Stanford.EDU:hayes.pa@Xerox.COM Re: disk use charges
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Oct 88 14:34:39 PDT
Received: from Xerox.COM by SCORE.STANFORD.EDU with TCP; Tue 11 Oct 88 13:52:52-PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 OCT 88 13:51:46 PDT
Date: 11 Oct 88 13:51 PDT
From: hayes.pa@Xerox.COM
Subject: Re: disk use charges
In-reply-to: John McCarthy <JMC@SAIL.Stanford.EDU>'s message of 09 Oct 88
13:57 PDT
To: John McCarthy <JMC@SAIL.Stanford.EDU>
cc: faculty@SCORE.STANFORD.EDU, su-computers@SAIL.Stanford.EDU
Message-ID: <881011-135146-6304@Xerox>
Its easy for me, since I dont have any over there, but Im behind you on
this files issue. I recently logged in to SAIL to send a mail message, and
promptly got a bill for around $50 for the filespace occupied by two years
back mail, which I was obliged to flush.
There is a general tendency for administrative systems to start doing
things to suit themselves rather than the people for whose convenience they
exist. If theres no good reason to overcharge, dont do it. And if there
is, lets all see it stated in clear nonlegalistic prose.
Pat Hayes
∂11-Oct-88 2008 DELAGI@SUMEX-AIM.Stanford.EDU [Eugene Miya <eugene@orville.nas.nasa.gov>:]
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Oct 88 20:08:44 PDT
Date: Tue, 11 Oct 88 17:01:51 PDT
From: Bruce A. Delagi <DELAGI@SUMEX-AIM.Stanford.EDU>
Subject: [Eugene Miya <eugene@orville.nas.nasa.gov>:]
To: aap@SUMEX-AIM.Stanford.EDU
Message-ID: <12437684562.40.DELAGI@SUMEX-AIM.Stanford.EDU>
Return-Path: <fpst@HUBCAP.CLEMSON.EDU>
Received: from RELAY.CS.NET by SUMEX-AIM.Stanford.EDU with TCP; Tue, 11 Oct 88 16:09:45 PDT
Received: from hubcap.clemson.edu by RELAY.CS.NET id aa10125;
11 Oct 88 14:50 EDT
Received: by hubcap.clemson.edu; Tue, 11 Oct 88 14:42:29 edt
Date: Tue, 11 Oct 88 14:42:29 edt
Message-Id: <8810111842.AA09734@hubcap.clemson.edu>
To: DELAGI%SUMEX-AIM.Stanford.EDU@RELAY.CS.NET,
coraki!pratt%Sun.COM@RELAY.CS.NET, cvb%daresbury.ac.uk@RELAY.CS.NET,
develo%waikato.ac.nz@RELAY.CS.NET, dwk%cs.tufts.edu@RELAY.CS.NET,
gopalakr%enuxha.asu.edu@RELAY.CS.NET,
hcube-users%hamlet.caltech.edu@RELAY.CS.NET,
hcube-users%mtu.edu@RELAY.CS.NET, scherrer%lovada.dec.com@RELAY.CS.NET
Newsgroups: comp.parallel
From: Eugene Miya <eugene@orville.nas.nasa.gov>
Subject: Usenix Unix and Supercomputers Workshop
Approved: parallel@hubcap.clemson.edu
I was sent mail and asked to summarize my thoughts on this workshop.
I think it was generally pretty good for a first workshop. In
the past, I attended the 1st and 2nd Usenix Graphics Workshops,
both had attendence less than 100 (the usual maximum set by Usenix).
This conference had 183 attendees. We discovered problems of
the physical layout of the hotel within the first hours, but the
attendees took it in stride. Contents appear below (excepting
work in progress reports (The Fujitsu UTS on their VP line was
perhaps most significant as they had planned to announce next year,
a "scoup!"). The general atmosphere was not as free flowing as
most Usenix meetings, in fact, there were times (people asked
themselves if they were attending a CUG [Cray User Group]
meeting. There were no Hypercube papers (possibly some in the
future, few Crayette papers, and I thought the technical
content to be a bit light (comments returned to Lori and Melinda
indicated most thought it was just right). There were a fair
number of people attending the /usr/group/supercomputing POSIX
standards meeting [following the workshop, I was asked to attend,
but could not due to prior commitments]. I think future meetings
will have a better idea of how to organize and have fun, share software,
etc. There is clearly big money in supercomputers, and the attendence
surprised all in a year when there are too many supercomputer
meetings.
--eugene miya
%A Jan Edler
%A Jan Lipkis
%A Edith Schonberg
%Z NYU Ultracomputer Project
%T Process Management for High Parallel UNIX Systems
%J Proc. Workshop on UNIX and Supercomputers
%I Usenix Assoc.
%C Pittsburgh, PA
%D Sept. 1988
%P 1-17
%K MIMD, RP3, fork, spawn, scheduling group ID, meta-system call,
temporary non-preemption, IPC, signal,
%A Dennis Ritchie
%Z AT&T Bell Labs
%T A Guest Facilities fpr Unicos
%J Proc. Workshop on UNIX and Supercomputers
%I Usenix Assoc.
%C Pittsburgh, PA
%D Sept. 1988
%P 19-24
%K virtual machines, exguest(XP), testing, simulator, Cray-XMP,
%A H. Stehpen Anderson
%Z OSCP, OSC
%T Distributed Supercomputer Graphics Using UNIX Tools
%J Proc. Workshop on UNIX and Supercomputers
%I Usenix Assoc.
%C Pittsburgh, PA
%D Sept. 1988
%P 25-32
%K distributed visualization, network, animation, apE, chimp,
remote shells, filters, Convex, Cray X-MP,
%A Jonathan Brown
%Z NMFECC LLNL
%T The CTSS/POSIX Project
%J Proc. Workshop on UNIX and Supercomputers
%I Usenix Assoc.
%C Pittsburgh, PA
%D Sept. 1988
%P 33
%K Cray,
%X Abstract only.
%A Robert M. Panoff
%Z Physics, Clemson U.
%T Real Producitivity for Real Science without Real Unix
%J Proc. Workshop on UNIX and Supercomputers
%I Usenix Assoc.
%C Pittsburgh, PA
%D Sept. 1988
%X Abstract only. "increased productivity of current supercomputer
users
appears doubtful..." poor compilers, inadequate debugging,
process proliferation as problems.
%A C. A. Stewart
%T Numerical Applications Interprocess Communication Protocol: RPCODE:
RPC server to solve ODEs
%J Proc. Workshop on UNIX and Supercomputers
%I Usenix Assoc.
%C Pittsburgh, PA
%D Sept. 1988
%P 37-42
%K Cray, SUN XDR,
%X Interesting JSR quote RPC1057.
%A Kenneth Bobey
%Z Myrias
%T Monitoring Program Performance on Large Parallel Systems
%J Proc. Workshop on UNIX and Supercomputers
%I Usenix Assoc.
%C Pittsburgh, PA
%D Sept. 1988
%P 43-49
%K profiling, parallel programmer's workbench (PPWB),
%A E. N. Miya
%T Some Observations on Computer Performance Characterization:
Supercomputer and Mini-Supercomputer Clocks and Compilers
%J Proc. Workshop on UNIX and Supercomputers
%I Usenix Assoc.
%C Pittsburgh, PA
%D Sept. 1988
%P 51-65
%K optimization, Cray, Convex, Cydra 5, amdahl, alliant, IBM,
%A John Renwick
%Z Cray
%T High-speed Network with Supercomputers
%J Proc. Workshop on UNIX and Supercomputers
%I Usenix Assoc.
%C Pittsburgh, PA
%D Sept. 1988
%P 67
%K Ultrabus, HSX, HSC,
%X Abstract only.
%A Ray Bryant
%Z IBM TJW
%T The RP3 Parallel Computing Environment
%J Proc. Workshop on UNIX and Supercomputers
%I Usenix Assoc.
%C Pittsburgh, PA
%D Sept. 1988
%P 69-92
%K Mach, AIX Transparent computing facility (Locus), ROMP, EPEX/CMS,
tasks threads (TTM), seamless system image,
%X Project survey, no new information, emphasis on batch rather than
interactive execution.
%A Brewster U. Kahle
%A William A. Nesheim
%A Marshall Isman
%Z Thinking Machines
%T UNIX and the Connection Machine Operating System
%J Proc. Workshop on UNIX and Supercomputers
%I Usenix Assoc.
%C Pittsburgh, PA
%D Sept. 1988
%P 93-107
%K CMOS, CM file systems (CMFS), virtual processor,
%X Good paper
%A Y. Langue
%A T. Muntean
%Z U. Grenoble
%T PARX: A Unix-like Operating System for Transputer-based Parallel
Supercomputers
%J Proc. Workshop on UNIX and Supercomputers
%I Usenix Assoc.
%C Pittsburgh, PA
%D Sept. 1988
%P 109-120
%K Occam, Minix, supernode, MIMD, SIMD, SPMD,
%A Martin Fouts
%T Multitasking under Unicos: Experiences with the Cray 2
%J Proc. Workshop on UNIX and Supercomputers
%I Usenix Assoc.
%C Pittsburgh, PA
%D Sept. 1988
%P 121-131
%K microtasking, Cray,
%X Elliptical Gauss-Seidel block diagonal solver.
%A Ralph Knag
%Z AT&T Bell Labs
%T Unicos Fair Share Scheduler
%J Proc. Workshop on UNIX and Supercomputers
%I Usenix Assoc.
%C Pittsburgh, PA
%D Sept. 1988
%P 133
%X Abstract only.
%A Kevin Wohlever
%T UNICOS System Administration at the Ohio Supercomputer Center
Tuning Considerations
%J Proc. Workshop on UNIX and Supercomputers
%I Usenix Assoc.
%C Pittsburgh, PA
%D Sept. 1988
%P 135-136
%X Extended abstract only. Copies of the paper exist (not bad).
%A Patrick Clancy
%Z Multiflow
%T Virtual Memory Extensions on TRACE/UNIX
%J Proc. Workshop on UNIX and Supercomputers
%I Usenix Assoc.
%C Pittsburgh, PA
%D Sept. 1988
%P 137-150
%K VLIW, copy on write, block allocation,
%A Jan Edler
%A Jan Lipkis
%A Edith Schonberg
%Z NYU Ultracomputer Project
%T Memory Management in Symunix II:
A Design for Large-Scale Shared Memory Multiprocessors
%J Proc. Workshop on UNIX and Supercomputers
%I Usenix Assoc.
%C Pittsburgh, PA
%D Sept. 1988
%P 151-168
%K Symunix I (Ultra I and II), cache, paging,
%X Several added systems calls.
%A E. C. Pariser
%Z AT&T Bell Labs
%T Reduction of Static and Dynamic Memory Requirements
on the Cray X-MP
%J Proc. Workshop on UNIX and Supercomputers
%I Usenix Assoc.
%C Pittsburgh, PA
%D Sept. 1988
%P 169-182
%K solid-state disk (SSD),
%X The memory management is static or dynamic, not the memory
technology (a somewhat unfortunate title). A significant I/O
performance
table.
%A Michael John Muuss
%A Terry Slattery
%A Donald F. Merritt
%T BUMP: The BRL/USNA Migration Project
%J Proc. Workshop on UNIX and Supercomputers
%I Usenix Assoc.
%C Pittsburgh, PA
%D Sept. 1988
%P 183-214
%K Cray,
%X What to do on "no space on disk."
%A Alan Poston
%T A High Performance File System for UNIX
%J Proc. Workshop on UNIX and Supercomputers
%I Usenix Assoc.
%C Pittsburgh, PA
%D Sept. 1988
%P 215-226
%K HPFS, amdahl UTS,
%X Proposal, work in progress.
%A Douglas E. Engert
%Z Argonne NL
%T Attaching IBM Disks Directly to a Cray-XMP
%J Proc. Workshop on UNIX and Supercomputers
%I Usenix Assoc.
%C Pittsburgh, PA
%D Sept. 1988
%P 227-229
%K XIOP, Block Multiplexer Controller (BMC),
%X Low cost, modest performance, software only changes
(no added hardware).
-------
∂12-Oct-88 1233 @Score.Stanford.EDU:katiyar@polya.Stanford.EDU potluck volunteers!
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Oct 88 12:33:08 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 12 Oct 88 12:22:30-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA04205; Wed, 12 Oct 88 12:23:52 PDT
Date: Wed, 12 Oct 1988 12:23:51 PDT
From: "Dinesh H. Katiyar" <katiyar@polya.stanford.edu>
To: faculty@score, research-associates@score
Cc: jaikumar@polya.Stanford.EDU, katiyar@polya.Stanford.EDU,
anderson@polya.Stanford.EDU
Subject: potluck volunteers!
Message-Id: <CMM.0.87.592687431.katiyar@polya.stanford.edu>
It has become a tradition within the department to hold a
Autumn Quarter potluck every year. In the past, these events have been
hosted by faculty members and research associates who have graciously
volunteered their homes for an evening.
Plans are underway to continue with the traditional potluck,
but a location for this year's event has not yet been found. If you
are interested in serving as this year's host, please let me know.
The only timing constraint is that the potluck should take place some
time soon after midterms (probably the second/third week of November).
As the organizational details of the event will all be handled by the Student
Social Committee, the inconvenience to the host should be kept to a
minimum. Thanks!
Jennifer Anderson
anderson@polya
Jaikumar Ramanathan
jaikumar@polya
Dinesh Katiyar
katiyar@polya
∂12-Oct-88 1539 @Score.Stanford.EDU:WIEDERHOLD@SUMEX-AIM.Stanford.EDU Re: disk use charges
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Oct 88 15:39:51 PDT
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 12 Oct 88 15:35:30-PDT
Date: Wed, 12 Oct 88 15:31:26 PDT
From: Gio Wiederhold <WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
Subject: Re: disk use charges
To: hayes.pa@Xerox.COM
cc: JMC@SAIL.Stanford.EDU, faculty@score.Stanford.EDU,
su-computers@SAIL.Stanford.EDU
In-Reply-To: <881011-135146-6304@Xerox>
Message-ID: <12437930245.85.WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
The lower disk charges, as set intially on Polya, caused me to invest time
to move files there. Now they are similar to all systems. Rather than fight
administrators I'll equip my workstations with adequate storage. That does
put the administrative burden on me and my students, but I can plan at least
ahead. Gio.
-------
∂12-Oct-88 1822 emma@csli.Stanford.EDU CSLI Calendar, October 13, 4:4
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Oct 88 18:21:55 PDT
Received: by csli.Stanford.EDU (4.0/4.7); Wed, 12 Oct 88 17:13:00 PDT
Date: Wed, 12 Oct 88 17:13:00 PDT
From: emma@csli.Stanford.EDU (Emma Pease)
To: friends@csli.Stanford.EDU
Subject: CSLI Calendar, October 13, 4:4
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
13 October 1988 Stanford Vol. 4, No. 4
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR NEXT THURSDAY, 13 October 1988
12 noon TINLunch
Cordura Hall Readings: "Situation Semantics and Semantic
Conference Room Interpretation in Constraint-based Grammars"
by Per-Kristian Halvorsen, and
"Projections and Semantic Description in
Lexical-Functional Grammar"
by Per-Kristian Halvorsen and Ronald M. Kaplan
discussion led by Mary Dalrymple
(maryd@ai.sri.com)
Abstract below
2:15 p.m. CSLI Seminar
Cordura Hall Psychological Processes in Resolution
Conference Room Herb Clark
(herb@psych.stanford.edu)
no abstract
3:45 p.m. Tea
Ventura Hall
____________
CSLI ACTIVITIES FOR NEXT THURSDAY, 20 October 1988
12 noon TINLab
Cordura Hall What IS Situated Language
Conference Room by John Perry
Abstract in next week's Calendar
2:15 p.m. CSLI Seminar
Cordura Hall Herb Clark
Conference Room (herb@psych.stanford.edu)
Abstract in next week's Calendar
3:45 p.m. Tea
Ventura Hall
4:00 p.m. STASS Seminar
Cordura Hall Points of View in Situation Semantics
Conference Room Yasuhiro Katagiri
Nippon Telegram and Telephone Corp.
____________
THIS WEEK'S TINLUNCH
Readings: "Situation Semantics and Semantic Interpretation
in Constraint-Based Grammars" by Per-Kristian Halvorsen
and
"Projections and Semantic Description in Lexical-Functional Grammar"
by Per-Kristian Halvorsen and Ronald M. Kaplan
Discussion led by Mary Dalrymple
(maryd@ai.sri.com)
13 October
The semantic approach described in these papers differs from other
approaches in several ways. First, the relation between an utterance
and its meaning is expressed in terms of correspondences between
structures rather than in terms of a derivational relationship between
structures. There is no sense in which a representation is
transformed or analyzed to produce a second structure. Second,
semantic structure is seen as a description specifying the properties
of a semantic object, in contrast with approaches where the semantic
object itself is constructed during the derivation of the sentence.
Third, projections are used in representing the relation between the
semantic structure and other relevant structures in the analysis of an
utterance and are claimed to provide a perspicuous way of representing
this relationship.
____________
STASS SEMINAR
Points of View in Situation Semantics
Yasuhiro Katagiri
Nippon Telegram and Telephone Corp.
Thursday, 20 October, 4:00 p.m. to 5:30 p.m.
Cordura Conference Room
In this talk, perspectival utterances, or utterances involving points
of view, are analyzed within the situation semantics framework. The
following two important features of those utterances are accounted for
by introducing notions of point-of-view situations and point-of-view
parameters along with a general picture of linguistic communication.
The two features are
(1) two-way dependence of utterances and points of view, and
(2) the fact that hearers normally take over speakers'
perspectives in comprehending perspectival utterances.
Relationships of the notion of perspectivity to quasi-indicators are
also discussed.
Copies of the full paper are available at the shelf behind the
receptionist's desk.
____________
SYMBOLIC SYSTEMS FORUM
The Symbolic Systems Forum hosts talks and presentations on any
subject even tangentially related to symbolic systems: subjects
ranging from neurophysiology, to various theoretical aspects of
computation, to philosophical perspectives on the mind and knowledge,
to cognitive psychology, to artificial intelligence, to history of
computing, to connectionism, to linguistics and to semiotics. The
motivation behind the forum is twofold. First, the Forum seeks to
bring together some unifying picture of the similarities and
dissimilarities of the work in these disparate fields: it seeks to
build the grand unifying picture underlying the technical work in the
field. Second, the Forum attempts to raise various issues for
discussion and to encourage the exchange of ideas between faculty and
students. Ideally, as each student and faculty member brings to the
forum their particular experience and particular field of study, the
discussions at the Forum will give rise to new ideas. To participate,
either join the symbolic systems faculty or send your name and e-mail
address to hoffman@csli via e-mail to be put on the mailing list.
The Forum is open to the general public, and is held almost
every Friday in room 62N in Building 60 in the quad. This Friday,
14 October, Professor Ivan Sag will speak on linguistics and
symbolic systems, explaining how linguistics interrelates with the
other disciplines within symbolic systems and what role linguistics
plays within symbolic systems. In detail, with a heavy emphasis on
linguistics, he will cover how the methodologies of the four
departments have combined to develop a new field of symbolic
systems.
On Friday, 21 October, Professor John McCarthy will speak on
formalizing commonsense knowledge and reasoning into logic.
Professor McCarthy is one of the cofounders of artificial
intelligence and most of his work lies with logic.
--------------
NEW PUBLICATIONS
The following reports have recently been published. They may be
obtained, or a full list acquired by writing to Trudy Vizmanos,
CSLI, Ventura Hall, Stanford, CA 94305-4115, or
publications@csli.stanford.edu.
112. Bare Plurals, Naked Relatives, and Their Kin.
Dietmar Zaefferer $2.50
113. Events and ``Logical Form''. Stephen Neale $2.00
114. Backwards Anaphora and Discourse Structure: Some
Considerations. Peter Sells $2.50
115. Toward a Linking Theory of Relation Changing Rules in LFG.
Lori Levin $4.00
116. Fuzzy Logic. L. A. Zadeh $2.50
117. Dispositional Logic and Commonsense Reasoning.
L. A. Zadeh $2.00
118. Intention and Personal Policies. Michael Bratman $2.00
119. Propositional Attitudes and Russellian Propositions.
Robert C.Moore $2.50
120. Unification and Agreement. Michael Barlow $2.50
121. Extended Categorial Grammar. Suson Yoo and Kiyong Lee $4.00
122. The Situation in Logic---IV: On the Model Theory of Common
Knowledge. Jon Barwise $2.00
123. Unaccusative Verbs in Dutch and the Syntax-Semantics Interface.
Annie Zaenen $3.00
124. What Is Unification? A Categorical View of Substitution,
Equation and Solution. Joseph A. Goguen $3.50
125. Types and Tokens in Linguistics. Sylvain Bromberger $3.00
126. Determination, Uniformity, and Relevance: Normative Criteria
for Generalization and Reasoning by Analogy.
Todd Davies $4.50
127. Modal Subordination and Pronominal Anaphora in Discourse.
Craige Roberts $4.50
128. The Prince and the Phone Booth: Reporting Puzzling Beliefs.
Mark Crimmins and John Perry $3.50
129. Set Values for Unification-Based Grammar Formalisms and Logic
Programming. William Rounds $4.00
130. Fifth Year Report of the Situated Language Research Program.
free
131. Locative Inversion in Chichewa: A Case Study of Factorization
in Grammar. Joan Bresnan and Jonni M. Kanerva $5.00
132. An Information-Based Theory of Agreement.
Carl Pollard and Ivan A.Sag $4.00
∂12-Oct-88 1833 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu important meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Oct 88 18:33:43 PDT
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 12 Oct 88 17:26:30-PDT
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA18260; Wed, 12 Oct 88 17:19:33 PDT
Date: Wed, 12 Oct 88 17:19:33 PDT
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8810130019.AA18260@Tenaya.stanford.edu>
To: tenured@score
Cc: phy@sail, bscott@score
Subject: important meeting
There will be a meeting of the tenured faculty of the CS Department
next Tuesday, October 18 at 2:30 p.m. (Joyce will find us a room, and
the room number will be announced.) The single item on the agenda is
to act on the recommendations of the theory search committee to offer a
faculty position as a Professor of Computer Science to Fan Chung and
also to appoint her as Director of the proposed new Center for
Computation Theory. It will be important for all to read the
evaluation letters that we have obtained before the faculty meeting.
In order to protect their privacy, these letters are being kept in
Phyllis Winkler's office (mjh 328). Please stop by her office and
make arrangements to read them.
I want to thank the theory search committee, chaired this year by Don
Knuth, for its diligent work in screening candidates and arriving at a
recommendation in such a timely manner. Restoring Stanford's
reputation in the foundations of computer science is of great
strategic importance to the Department, so I hope all of you will be
able to attend the meeting and participate in this decision.
Thanks, -Nils
∂12-Oct-88 2009 LOGMTC-mailer Mark Manasse's email address?
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Oct 88 20:08:48 PDT
Received: from localhost by russell.Stanford.EDU (4.0/4.7); Wed, 12 Oct 88 20:09:34 PDT
To: logic@russell.Stanford.EDU
Subject: Mark Manasse's email address?
Date: Wed, 12 Oct 88 20:09:33 PDT
From: Jon Barwise <barwise@russell.Stanford.EDU>
I see from the front page of the NY Times
that a former logic student at Wisconsin,
Mark Manasse, is at DEC in PA. Anyone
know his address?
∂12-Oct-88 2351 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu Re: disk use charges
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Oct 88 23:51:53 PDT
Received: from Pescadero by SCORE.STANFORD.EDU with TCP; Wed 12 Oct 88 23:47:54-PDT
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA21303; Wed, 12 Oct 88 23:51:04 PDT
Date: Wed, 12 Oct 88 23:51:04 PDT
From: "David Cheriton" <cheriton@pescadero.stanford.edu>
Message-Id: <8810130651.AA21303@Pescadero>
To: WIEDERHOLD@sumex-aim.Stanford.EDU, hayes.pa@xerox.com
Subject: Re: disk use charges
Cc: JMC@sail.Stanford.EDU, faculty@score.Stanford.EDU,
su-computers@sail.Stanford.EDU
In-Reply-To: <12437930245.85.WIEDERHOLD@SUMEX-AIM.Stanford.EDU> from Gio
Wiederhold <WIEDERHOLD@SUMEX-AIM> on Wed, 12 Oct 88 15:31:26 PDT
I find some of this disk use charge discussion strange.
For one, it is true that storage is cheaper now than it has ever been.
I have an optical disk with 2 Gbytes that would not only allow JMC to
keep things on line but, as a WORM, precludes ever deleting. $300 per
2 gigabyte platter plus a jukebox to keep them on-line. However,..
Most of CSD-CF budget is people, and that's the big cost. So, when Gio
talks about taking the "adminstrative burden" on himself and students,
either he can manage systems in less time thatn CSD-CF or else his time
is cheaper to him, or ??
I see two major problems.
For one, we (the computing community) have done a poor job to date of
automating backup/archive, etc. procedures and its not even clear that the
derivative is positive. I understand that Sail and Tops-20 are better than
Unix in this regard (not saying much).
We are really in the dark ages when it comes to self-maintaining storage
systems - so CSD-CF incurs significant person time to provide a reliable
storage system - the alteratnive right now is unreliable service.
Secondly, we are running a enormous range of systems, from Sail to
score to Vax/Unix systems to SUN file servers, all of which are different
and brain-damaged in ways that will make our grandchildren shake their
heads in wonder. We pay to survive in this menegarie.
David C.
∂13-Oct-88 1004 emma@csli.Stanford.EDU CSLI Calendar, addition
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Oct 88 10:04:20 PDT
Received: by csli.Stanford.EDU (4.0/4.7); Thu, 13 Oct 88 09:00:55 PDT
Date: Thu, 13 Oct 88 09:00:55 PDT
From: emma@csli.Stanford.EDU (Emma Pease)
To: friends@csli.Stanford.EDU
Subject: CSLI Calendar, addition
Here is an announcement that failed to make it into the last Calendar.
CSLI SEMINAR
The Resolution Problem for Natural Language Processing
Weeks 3 and 4: Psychological Processes
Herb Clark
(herb@psych.stanford.edu)
Thursday, 13 and 20 October
2:15
Today and next Thursday I will review part of what is known about the
process of resolving ambiguities and indeterminacies from work in
psychology. Today I will take up, among other things, the issues of
automaticity and modularity in resolving structural ambiguities--that
is, ambiguous words, attachment ambiguities, and other local parsing
ambiguities. The question is, how are these ambiguities resolved so
quickly and apparently automatically on the basis of lexical,
syntactic, semantic, and pragmatic information, and what does this say
about the process of understanding in general? Next week I will take
up the more pragmatic issues in resolution, such as how people resolve
references, illocutionary force, and implicatures, and how speakers
and listeners manage to do this collectively.
∂13-Oct-88 1403 hoffman@csli.Stanford.EDU Symbolic Systems Forum Oct. 14
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Oct 88 14:03:00 PDT
Received: by csli.Stanford.EDU (4.0/4.7); Thu, 13 Oct 88 14:01:56 PDT
Date: Thu 13 Oct 88 14:01:52-PDT
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: Symbolic Systems Forum Oct. 14
To: ssp-faculty@csli.Stanford.EDU, ssp-students@csli.Stanford.EDU,
ssp-forum@csli.Stanford.EDU
Message-Id: <592779713.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
This Friday (at 3:15 in room 62N as usual) we have Ivan Sag speaking on
Linguistics and Symbolic Systems, exploring how ideas and methodology in
linguistics contribute to creating a Symbolic Systems discipline.
As I have heard him speak, I can personally recommend Professor Sag as
an excellent speaker.
-------
∂13-Oct-88 1528 tah@linz MTC Seminar
Received: from linz.stanford.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88 15:28:06 PDT
Received: by linz.stanford.edu (4.0/SMI-DDN)
id AA18767; Thu, 13 Oct 88 15:24:01 PDT
Message-Id: <8810132224.AA18767@linz.stanford.edu>
To: alur@polya, arean@polya, barwise@russell, bhoward@polya, chavez@sumex-aim,
clt@sail, coraki!pratt@sun.com, crew@polya, devlin@csli, dill@amadeus,
eswolf@polya, fernando@csli, galbiati@polya, grove@polya,
gurevich@polya, herskovits@sumex-aim, hirani@sun.com, howard@polya,
jcm@ra, jmc-lists@sail, kar@polya, kolaitis@polya, lincoln@polya,
lowry@coyote, ma@src.dec.com, martin@polya, mb@jeeves, mcguire@polya,
shankar@score, olthoff@hplabs.hp.com, peters@russell, pieper@geode,
polaschek@sumex-aim, rdz@score, rjw@sail, roach@score, rtc@sail,
sf@csli, traugott@jeeves, val@sail, vardi@polya, vasilis@polya,
weening@gang-of-four, zm@sail, tah@linz
Cc: csd@score
Subject: MTC Seminar
Date: 13 Oct 88 15:23:56 PDT (Thu)
From: Tom Henzinger <tah@linz>
Change of room: the seminar will be Fridays at 12 noon in MJH 301.
Topic for Oct. 14: we're going to start reading Dana Scott's "Relating
Theories of the Lambda-Calculus" (in To H.B. Curry, Seldin and Hindley,
eds.). Copies of the paper are still available from Rosemary Napier
(MJH 340).
∂13-Oct-88 1532 @Score.Stanford.EDU:WIEDERHOLD@SUMEX-AIM.Stanford.EDU Re: disk use charges
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Oct 88 15:31:21 PDT
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 13 Oct 88 15:23:54-PDT
Date: Thu, 13 Oct 88 13:53:22 PDT
From: Gio Wiederhold <WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
Subject: Re: disk use charges
To: hayes.pa@Xerox.COM
cc: faculty@score.Stanford.EDU
In-Reply-To: <881013-124926-4526@Xerox>
Message-ID: <12438174535.58.WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
I don't agree with your diagnosis. I don't see that things are being
given away, I pay for my students' use, and the department in some way
taxes us for unsupported students. Now the taxation may be unfair.
If it is based on usage of storage, a group which is likely to use
much storage suffers. Maybe we look rich, and taxing the rich has
always been a politically acceptable strategy. Unfortunatly, the
party that sold us polya, with promises of cheap storage can't keep
those promises. That happens in politics too.
However, I thnk that the problem is that the central organization (sp.:
American!) has some real costs: people, which keep increasing; while
hardware costs drop.
In a national organization such overheads amortize better than when we all
have suborganizations. So what are French taxes like?
There is a free-market alternative. I mentioned to CSD folk a long time ago
we should only have a facilities contracting person, rather than in-house
staff. That person would then deal with SUN specialists, VAX specialists,
etc. on the outside, including commercial sources. The tradeoff of cost and
response time is complex, but becomes visible. Currently mainly bosses, i.e.
administrators, get good service. Are there enough such contractors? (where
do we find SAIL contractors?).
Enough. Gio
-------
∂13-Oct-88 1903 @Score.Stanford.EDU:hayes.pa@Xerox.COM Re: disk use charges
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Oct 88 18:18:28 PDT
Received: from Xerox.COM ([13.0.12.232].#Internet) by SCORE.STANFORD.EDU with TCP; Thu 13 Oct 88 18:08:29-PDT
Received: from Semillon.ms by ArpaGateway.ms ; 13 OCT 88 12:49:26 PDT
Date: 13 Oct 88 12:48 PDT
From: hayes.pa@Xerox.COM
Subject: Re: disk use charges
In-reply-to: Gio Wiederhold <WIEDERHOLD@SUMEX-AIM.Stanford.EDU>'s message
of Wed, 12 Oct 88 15:31:26 PDT
To: Gio Wiederhold <WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
cc: hayes.pa@Xerox.COM, JMC@SAIL.Stanford.EDU, faculty@score.Stanford.EDU,
su-computers@SAIL.Stanford.EDU
Message-ID: <881013-124926-4526@Xerox>
Perhaps saying this is politically unwise, but the problem and your
solution seem to me to have a uniquely American flavor. Its a sort of 80s
bedtime story. The central organisation whose function is to serve the
needs of the community becomes unusable because it wants to charge the
market rate for its services, presumably feeling that to give the stuff
away to those who cant pay for it is somehow faintly immoral. Your
response is to accept its redefinition of its role as another agent in the
free market, and just find a cheaper way to look after yourself. The net
result is that those who, like yourself, are willing and able to somehow
get hard cash to buy what you want, wind up getting along OK, but those who
are unable or unwilling to get sufficiently rich, get screwed. And even
among those who win, more and more of their time gets used up in looking
for money, and cooperation and communication become more and more difficult
as the market forces encourage idiosyncracy. How many more kinds of
mutually incompatible "workstation with adequate storage" are there likely
to be on campus soon? Why is France, not the USA, the first country to
have a national computer-communication network in place?
Still, I really love it here and will remain loyal no matter who wins the
election. Really.
Pat
∂13-Oct-88 1910 @Score.Stanford.EDU:vavasis@polya.Stanford.EDU charge rates
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Oct 88 19:10:20 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 13 Oct 88 18:22:45-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA23290; Thu, 13 Oct 88 10:44:07 PDT
Date: Thu, 13 Oct 88 10:44:07 PDT
From: Stephen A. Vavasis <vavasis@polya.Stanford.EDU>
Message-Id: <8810131744.AA23290@polya.Stanford.EDU>
To: faculty@score, su-computers@score
Subject: charge rates
David Cheriton raised some interesting points on su-computers
about why the department is having trouble with computer charges.
There is an additional point I'd like to bring up: Why are faculty
members forced to berate CSD-CF on a bulletin board? Wasn't
CSD-CF set up as a convenience for the faculty? It seems to
me that the relationship between the faculty and CSD-CF ought
to be cooperative rather than adversarial.
When I got involved with the debate over polya charges last
spring, I soon learned that this factionalism was a major
cause of the trouble. CSD-CF was going to bill students'
advisors for polya time, but many faculty members were very
unhappy with CSD-CF charging policies, and the students were
caught in the middle.
The faculty should put their heads together and figure out
a workable way to handle shared computer facilities.
-- Steve Vavasis
∂14-Oct-88 1105 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Columbia theory seminars near FOCS
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Oct 88 11:05:12 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA04412; Fri, 14 Oct 88 11:04:46 PDT
Message-Id: <8810141804.AA04412@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 14 Oct 88 11:05:03 PDT
Received: by BYUADMIN (Mailer X2.00) id 5719; Fri, 14 Oct 88 12:02:18 MDT
Date: Fri, 14 Oct 88 12:46:21 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
David Eppstein <eppstein%GARFIELD.CS.COLUMBIA.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: David Eppstein <eppstein%GARFIELD.CS.COLUMBIA.EDU@Forsythe.Stanford.EDU>
Subject: Columbia theory seminars near FOCS
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
We will be offering the following theory seminars on the Thursdays before
and after FOCS, for those not too burnt out by the conference itself.
For those who have already seen this announcement, note the time change.
The seminars will be at 2:15, not 1:30.
**********************************
Generating random spanning trees
Andrei Broder
DEC Systems Research Center
2:15 p.m., Thursday, October 22, 1988
Conference Room, Computer Science Department, Columbia University
This talk presents a probabilistic algorithm that, given a connected,
undirected graph G with N vertices, produces a spanning tree of G chosen
uniformly at random among the spanning trees of G. The expected running
time is O(N ln N) per generated tree for almost all graphs, and O(N~3)
for the worst graphs. Previously known algorithms require O(N~5) time
per generated tree.
The new algorithm is based on the simulation of a Markov chain on the
space of the objects of interest, a technique that had recently seen
several very interesting applications to the the quasi-uniform
generation of certain combinatorial structures; here is an example where
this technique is used for the exactly uniform generation.
The talk is self contained; only a minimal background in the theory of
Markov chains is required.
**********************************
Shortest Paths without a Map
Christos Papadimitriou, U.C. San Diego
(Joint work with Mihalis Yannakakis, Bell Labs)
2:15 p.m., Thursday, October 27, 1988
Conference Room, Computer Science Department, Columbia University
We wish to find a path from where we are to a goal that avoids all obstacles,
and is as close to the optimum as feasible. The problem is that we do not
know the map beforehand, and we see the obstacles as they become visible.
For the case of obstacles that are parallel line segments, we give an
algorithm that achieves a ratio of 4 to the optimum; 4 is the best possible.
For slightly more general obstacles (segments in two perpendicular
directions) no bounded ratio is possible. We also show that designing a
search strategy that achieves the best ratio is PSPACE-complete.
∂14-Oct-88 1257 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu LICS-89 DEADLINE
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Oct 88 12:56:45 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA13580; Fri, 14 Oct 88 12:56:26 PDT
Message-Id: <8810141956.AA13580@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 14 Oct 88 12:57:04 PDT
Received: by BYUADMIN (Mailer X2.00) id 7370; Fri, 14 Oct 88 13:54:56 MDT
Date: Fri, 14 Oct 88 14:37:58 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Rohit Parikh <RIPBC%CUNYVM.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Rohit Parikh <RIPBC%CUNYVM.BITNET@forsythe.stanford.edu>
Subject: LICS-89 DEADLINE
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
EXTENSION OF LICS-89 DEADLINE FOR PAPER SUBMISSION
With the consent of the program committee, the deadline for submission
of papers for LICS-89 is extended to October 31, 1988 (firm) for receipt
of all submissions. This should save at least some people the cost of
EXPRESS mail. The revised version of the relevant portion from the call
for papers now goes as follows:
CALL FOR PAPERS
Logic in Computer Science (LICS)
Fourth Annual Symposium
June 5-8, 1989, Asilomar, California
Paper submission: 15 copies of a detailed abstract (not a full paper)
should be RECEIVED by October 31, 1988 by the program chairman:
Prof. Rohit Parikh - LICS
Department of Computer Science
Brooklyn College of CUNY
Bedford Avenue & Avenue H
Brooklyn, NY 11210, U.S.A.
Bitnet: RIPBC@CUNYVM Internet: ripbc@cunyvm.cuny.edu
NB: papers from outside the U.S.A. should also arrive by October 31.
∂14-Oct-88 1418 @Score.Stanford.EDU:wheaton@athena.stanford.edu Special-Needs Budget
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Oct 88 14:18:48 PDT
Received: from athena.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 14 Oct 88 14:13:50-PDT
Received: by athena.stanford.edu (4.0/SMI-DDN)
id AA03044; Fri, 14 Oct 88 14:17:04 PDT
Date: Fri, 14 Oct 88 14:17:04 PDT
From: wheaton@athena.stanford.edu (George Wheaton)
Message-Id: <8810142117.AA03044@athena.stanford.edu>
To: faculty@score
Subject: Special-Needs Budget
Again this year, the Provost is asking the Departments to submit
requests for Special-Needs Budget Items to be used to strengthen our
programs. A difference between this year's submittal and prior years'
is that we can now specify programs to be phased in over a three year
period instead of just the current year.
If anyone has specific requirements for additional funds, please send
me a description and justification of the program together with the
amount of funding, by year, that you will need over the three year
period.
There are several caveats that the Dean's and Provost's offices have
attached to the "offer". First, without specifying a number, the
Dean's office said they would not conssider "high flying" requests;
they did use a figure of $25,000 in an example. Second, do not
request funds for secretaries, telephones, or EM&S since those items
are already factored in to the budget process. Third, requests have a
greater chance of being approved if the organization also promises
some "consolidation", ie reduction in existing programs.
The time for submittal is short, and I must have your responses by
next Friday, Oct. 21. E-mail is OK, I'll pull them together.
George
∂14-Oct-88 1427 X3J13-mailer Issue: RANGE-OF-COUNT-KEYWORD (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Oct 88 14:26:15 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476697; Fri 14-Oct-88 17:26:16 EDT
Date: Fri, 14 Oct 88 17:26 EDT
From: CL-Cleanup@SAIL.Stanford.EDU
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Issue: RANGE-OF-COUNT-KEYWORD (Version 3)
To: X3J13@SAIL.Stanford.EDU
Supersedes: <881009001850.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-ID: <881014172603.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Issue: RANGE-OF-COUNT-KEYWORD
References: :COUNT (p247), REMOVE[-xxx] (p253), DELETE[-xxx] (p254),
[N]SUBSTITUTE[-xxx] (pp255-256)
Category: CLARIFICATION
Edit history: 21-Aug-88, Version 1 by Dave Touretzky
22-Aug-88, Version 2 by Pitman
09-Oct-88, Version 3 by Pitman
Status: For Internal Discussion
Problem Description:
CLtL is overly vague about legal values for the :COUNT keyword
parameters to builtin functions such as the sequence functions. It
says that the keyword ``limits the number of elements [affected]''.
Implementations have varied in their interpretation of this phrase,
however.
CLtL p247 specifies that if the :COUNT parameter to functions such
as REMOVE and DELETE ``is NIL or is not supplied, all matching items
are affected.'' Because of the placement of this requirement
outside of the description of the functions affected, some
implementations have overlooked this requirement and had to be
changed later.
CLtL doesn't say explicitly that the value of :COUNT must be an
integer, nor does it say what to do for negative values.
The fact that reasonable implementations disagree on some of the
details make this an obvious candidate for cleanup.
Proposal (RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER):
Clarify that for the functions
REMOVE REMOVE-IF REMOVE-IF-NOT
DELETE DELETE-IF DELETE-IF-NOT
SUBSTITUTE SUBSTITUTE-IF SUBSTITUTE-IF-NOT
NSUBSTITUTE NSUBSTITUTE-IF NSUBSTITUTE-IF-NOT
the following restrictions on the :COUNT keyword parameter exist:
* The value of this parameter must be NIL or an integer.
* Using a negative integer value is functionally equivalent to
using a value of zero.
Test Case:
#1: (REMOVE 'A '(A B A B) :COUNT 0) => (A B A B)
#2: (REMOVE 'A '(A B A B) :COUNT -3) => (A B A B)
#3: (REMOVE 'A '(A B A B) :COUNT NIL) => (B B)
#4: (REMOVE 'A '(A B A B) :COUNT 1.0) is an error.
#5: (REMOVE 'A '(A B A B) :COUNT 'FOO) is an error.
Rationale:
Disallowing non-integer numbers is probably the original intent and
is consistent with other functions such as NTH (p265) which accept
count-like arguments that are explicitly required to integers. This
restriction would presumably permit better optimizations in low-safety
mode on stock hardware.
Allowing NIL to be equivalent to no value allows a simplified flow
of control in some situations. For example, one can write
(DEFUN MYDEL (ITEM &OPTIONAL COUNT)
(DELETE ITEM *MYLIST* :COUNT COUNT))
where otherwise it might be necessary to write something like
(DEFUN MYDEL (ITEM &OPTIONAL (COUNT NIL COUNT-P))
(IF COUNT-P
(DELETE ITEM *MYLIST* :COUNT COUNT)
(DELETE ITEM *MYLIST*)))
Allowing negative numbers frees users from having to do an explicit
check for negative numbers when the value of :COUNT is computed by
some complicated expression. For example:
(DEFUN LEAVE-AT-MOST (N ITEM SEQUENCE &KEY (FROM-END T))
(REMOVE ITEM SEQUENCE
:COUNT (PRINT (- (COUNT ITEM SEQUENCE) N))
:FROM-END FROM-END))
(LEAVE-AT-MOST 2 #\A "BANANAS") ==> "BANANS"
(LEAVE-AT-MOST 2 #\S "BANANAS") ==> "BANANAS"
Current Practice:
[Note: Pitman didn't try these examples in KCL or CMU Common Lisp. He's
working from data in Touretzky's last draft of this proposal, so someone
from those camps might want to test the assertions made here.]
#1: All correct implementations presumably return (A B A B).
This value is consisent with this proposal.
#2: Symbolics Cloe returns (A B A B).
KCL returns (A B A B) for lists.
This value is forced by this proposal.
Symbolics Genera and CMU Common Lisp return (B B).
KCL does something bizarre for vectors (``pads with n blanks or
NILs, where -n is the value of the :count keyword parameter'',
says Touretzky.)
These implementations would have to change.
#3: All correct implementations presumably return (B B).
This value is consisent with this proposal.
Some implementations have been known to signal a wrong type
argument error in the past, but have presumably been fixed.
#4: Symbolics Genera and Symbolics Cloe return (B A B).
CMU Common Lisp returns (B B).
These behaviors are consistent with this proposal.
#5: Symbolics Cloe and Symbolics Genera signal an error.
CMU Common Lisp returns (A B A B).
These behaviors are consistent with this proposal.
Cost to Implementors:
Some implementations would have to change. These functions are typically
heavily optimized by compilers. Not only source code, but also compiler
optimizers and perhaps even microcode or hardware might have to be
modified to fully accomodate this change, so it might be quite expensive.
Cost to Users:
None for Common Lisp users. This change is an upward compatible
clarification of standard practice.
Cost of Non-Adoption:
The behavior of these functions when given degenerate keyword values would
be unintuitive. In many such cases, considerable additional user code must
be written to watch for and avoid creating such situations.
Benefits:
More compact, more intuitive, and more portable code.
Aesthetics:
This change improves language aesthetics.
Discussion:
In the past there has been some argument about what SUBSEQ should do when
given positions greater than the length of the sequence. Currently it
"is an error" to specify positions less than zero or greater than the
length of the sequence. Touretzky doesn't think the same should apply to
the :COUNT keyword. The inputs to SUBSEQ are ordinal numbers: they specify
positions, like array subscripts. The value of :COUNT is not an ordinal,
it is an upper bound on the size of the set of affected items (which is
a cardinal number).
Pitman supports this proposal. [Hopefully Touretzky supports it, too?]
van Roggen says he personally supports the stated proposal but that a
survey he did of users at DEC showed up a number of people who thought
that negative count arguments should be an error.
∂16-Oct-88 2322 misha@polya.Stanford.EDU Next AFLB is on Tuesday!
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Oct 88 23:22:46 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA22731; Sun, 16 Oct 88 23:20:33 PDT
Date: Sun, 16 Oct 88 23:20:33 PDT
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8810170620.AA22731@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: Next AFLB is on Tuesday!
Please note UNUSUAL time (and possibly place)!
The next AFLB will be on Tuesday October 18 at 12:30.
The room will most likely be the usual 352 in MJH;
if a change is necessary, I'll post the new room number.
On the Magnification of 0-1 Polytopes
Milena Mihail
Harvard University and U.C. Berkeley
A polytope in R↑n is a "0-1 polytope" if the coordinates of
its vertices are either 0 or 1. The "1-skeleton" of such a po-
lytope is a graph whose vertex set is the set of vertices of the
polytope and whose edges correspond to 1-dimensional faces
(edges) of the polytope. For several non-trivial combinatorial
objects - matchings, matroids, order ideal - interesting struc-
tural information can be expressed in terms of their associated
0-1 polytopes: the 1-skeletons of these polytopes are natural
"exchange-graphs".
We show strong magnification properties for the 1-skeletons of
the following classes of polytopes: (i) Arbitrary truncations of
the matching polytope. (ii) Arbitrary truncations of partition
matroid polytopes. (iii) The polytope of order ideals. The proof
technique is a probabilistic extension of Jerrum and Sinclair's
idea to "encode and bound paths using the state-space". New sam-
pling schemes for matchings follow as a concrete consequence of
these results.
We conjecture that the magnification properties of the specif-
ic polytopes listed above are examples of a more general
phenomenon : "All 0-1 polytopes are magnifying". A positive reso-
lution of this conjecture would imply efficient schemes for es-
timating the number of vertices of polytopes whose degrees are
bounded by a polynomial in n. Several unsolved counting problems
(including counting bases of a matroid and network reliability)
can be expressed in terms of counting the number of vertices of
suitably chosen polytopes that satisfy the condition of bounded
degrees.
- This is joint work with Umesh Vazirani -.
∂17-Oct-88 0814 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Tenured Faculty Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Oct 88 08:14:21 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 17 Oct 88 08:09:42-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA02199; Mon, 17 Oct 88 08:13:13 PDT
Date: Mon, 17 Oct 1988 8:13:09 PDT
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score
Subject: Tenured Faculty Meeting
Message-Id: <CMM.0.87.593104389.chandler@polya.stanford.edu>
Just a reminder that there will be a meeting of the tenured faculty on
Tuesday, October 18 in MJH146 at 2:30.
∂17-Oct-88 0910 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu ICLP89 --- CFP
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Oct 88 09:10:27 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA04863; Mon, 17 Oct 88 09:09:56 PDT
Message-Id: <8810171609.AA04863@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 17 Oct 88 09:10:31 PDT
Received: by BYUADMIN (Mailer X2.00) id 4341; Mon, 17 Oct 88 10:08:45 MDT
Date: Mon, 17 Oct 88 10:18:25 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
UDI%WISDOM.BITNET@forsythe.stanford.edu
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: UDI%WISDOM.BITNET@forsythe.stanford.edu
Subject: ICLP89 --- CFP
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Association for Logic Programming
ICLP -89
CALL FOR PAPERS
Sixth International Conference on Logic Programming
19-23 June 1989 - Lisboa, Portugal
The Association of Logic Programming is sponsoring the 6th International
Conference on Logic Programming. Previous ICLP meetings were held in
Marseille, Uppsala, London, Melbourne, and, joint with the Symposium on
Logic Programming, in Seattle.
Programme Chairman Conference Chairmen
Giorgio Levi, ICLP'89 Antonio Porto and Luis Moniz Pereira
Dipartimento di Informatica Departamento de Informatica
Universita' di Pisa Universidade Nova de Lisboa
Corso Italia, 40 Quinta da Torre
56100 Pisa 2825 Monte de Caparica
ITALY PORTUGAL
Conference Topics
Authors are invited to submit papers on all aspects of Logic Programming,
including, but not restricted to:
- Applications
- Architectures
- Complexity
- Concurrent Languages
- Constraint Languages
- Deductive Databases
- Higher-order Languages and Extensions
- Language Issues
- Program Development Tools and Methodology
- Relations to other Computational Models
- Relations with Artificial Intelligence
- Sequential and Parallel Implementations
- Theory and Foundations
Dates
Submission deadline: December 1, 1988
Notification of acceptance/rejection: March 1, 1989
Camera-ready copies due: April 1, 1989
Paper Submission
Submit five copies of manuscripts to the ICLP-89 Programme Chairman by
December 1, 1988. Papers are restricted to 4,000 words (12-14 double
spaced pages). Papers overlength will not be considered.
Each paper must contain a 200-250 word abstract, and must be written and
presented in English.
Papers should not be simultaneously submitted for publication elsewhere.
Important: Authors are requested to use first class/ex-press mail or
private carriers for their sub-missions: do not use printed-matter mail.
Please notify your submission by e_mail, telex or fax to M. Martelli:
e_mail: martelli@icnucevm.bitnet
telex: 500371 CNUCE I
fax: +39 - 50 - 576751
A limited number of ALP bursaries may be available to assist authors of
accepted papers who would not otherwise be able to attend the Conference.
Authors that have no access to copy machines can send a single copy.
Programme Committee
G. Levi
Univ. of Pisa, Pisa, Italy (Chairman)
K. R. Apt
CWI, Amsterdam, The Netherlands, and
Univ. of Texas at Austin, Austin, TX, USA
M. Bruynooghe
Katholieke Universiteit Leuven, Heverlee,
Belgium
T. Chikayama
ICOT,Tokyo, Japan
W.F. Clocksin
Univ. of Cambridge, Cambridge, UK
A. Colmerauer
Marseille,France
J. Connery
Univ.of Oregon, Eugene, OR, USA
M. Dincbas
ECRC, Munich, F.R. Germany
M. Genesereth
Standford Univ., Standford, CA, USA
M. Hermenegildo
MCC, Austin, TX, USA
C.J. Hogger
Imperial College,London ,UK
F. Kluzniak
Warszawa University, Warszawa, Poland
M.J. Maher
IBM-T.J. Watson Research Center, NY, USA
J. Maluszynski
Univ.of Linkoping, Linkoping, Sweden, and
Univ. of Utah, Salt Lake City, UT, USA
M. Martelli
CNUCE, Pisa, Italy
Y. Matsumoto
Kyoto University, Kyoto, Japan
F. G. McCabe
Imperial College, London, England
D. Miller
Univ. of Pennsylvania, Philadelphia, PA, USA
J. Minker
Univ. of Maryland, College Park, MD, USA
G. Mints
Estonian Academy of Science, Tullinn, USSR
L. Naish
Melbourne Univ., Melbourne, Australia
R. Overbeek
Argonne National Laboratory, Argonne, IL, USA
L. M. Pereira
Univ. of Lisboa, Lisboa, Portugal
A. Porto
Univ. of Lisboa, Lisboa, Portugal
T. O. Przymusinski
Univ. of Texas at El Paso, El Paso, TX, USA
Y. Sagiv
Hebrew University, Jerusalem, Israel
E. Y. Shapiro
Weizmann Institute of Science, Rehovot, Israel
O. Shmueli
Israel Institute of Technology, Haifa, Israel
C. Zaniolo
MCC, Austin, TX, USA
∂17-Oct-88 1205 helen@russell.Stanford.EDU SSP-lunch
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Oct 88 12:05:48 PDT
Received: by russell.Stanford.EDU (4.0/4.7); Mon, 17 Oct 88 12:07:19 PDT
Date: Mon 17 Oct 88 12:07:18-PDT
From: Helen Nissenbaum <HELEN@CSLI.Stanford.EDU>
Subject: SSP-lunch
To: ssp-faculty@russell.Stanford.EDU
Message-Id: <593118438.0.HELEN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
A Reminder: SSP luncn meeting
October 21, noon
Cordura Hall Conference Room
We're ordering lunches. Please let me know if you're going to
be able to make the meeting. There were many responses to our earlier
announcement. If you have replied, thank you -- there's no need to
respond again.
Hope to see you Friday.
Helen Nissenbaum
-------
∂17-Oct-88 1233 DAVIS@Score.Stanford.EDU scheduling book
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Oct 88 12:33:45 PDT
Date: Mon 17 Oct 88 11:46:33-PDT
From: Thea Davis <DAVIS@Score.Stanford.EDU>
Subject: scheduling book
To: CSD-list@Score.Stanford.EDU
Message-ID: <12439200025.20.DAVIS@Score.Stanford.EDU>
Somehow the room scheduling book has disappeared. Maybe one of you
accidently lifted it. However, I reeeeally need that book. So would
you all be so kind and check to see if you have it. I promise not to
prosecute.
Thea
-------
∂17-Oct-88 1249 @Score.Stanford.EDU:chandler@polya.Stanford.EDU 10/19 Faculty Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Oct 88 12:47:11 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 17 Oct 88 12:20:11-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA17261; Mon, 17 Oct 88 11:57:51 PDT
Date: Mon, 17 Oct 1988 11:55:45 PDT
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score, spirou@polya.Stanford.EDU,
r.rhino@macbeth
Cc: nilsson@tenaya
Subject: 10/19 Faculty Lunch
Message-Id: <CMM.0.87.593117746.chandler@polya.stanford.edu>
.....just to remind you about tomorrow's faculty lunch. No topic....no
guest...just come join your colleagues for conversation and lunch. See you there!
∂17-Oct-88 1318 @SUMEX-AIM.Stanford.EDU:mxh@ksl.Stanford.EDU Hoare on SIMD
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Oct 88 13:18:07 PDT
Received: from ksl.Stanford.EDU by SUMEX-AIM.Stanford.EDU with TCP; Mon, 17 Oct 88 13:11:54 PDT
Received: by ksl.Stanford.EDU (4.0/inc-1.0)
id AA05890; Mon, 17 Oct 88 13:17:41 PDT
Date: Mon, 17 Oct 1988 13:17:40 PDT
From: Max Hailperin <mxh@ksl.stanford.edu>
Subject: Hoare on SIMD
To: aap@aim.stanford.edu
Message-Id: <CMM.0.88.593122660.mxh@ksl.stanford.edu>
For your amusement, an interesting observation on SIMD.
At that symposium, Dennis Parkinson (designer of the DAP) told Hoare's
reaction when Parkinson described his idea for the DAP to him. Roughly,
it was: "That's not a multiprocessor, that's a normal uniprocessor with
a rather long word-length and a somewhat peculiar instruction set."
∂17-Oct-88 1436 ullman@polya.Stanford.EDU ICLP call
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Oct 88 14:35:55 PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA00758; Mon, 17 Oct 88 14:31:24 PDT
Date: Mon, 17 Oct 88 14:31:24 PDT
From: Jeffrey D. Ullman <ullman@polya.Stanford.EDU>
Message-Id: <8810172131.AA00758@polya.Stanford.EDU>
To: nail@polya.Stanford.EDU
Subject: ICLP call
Association for Logic Programming
ICLP -89
CALL FOR PAPERS
Sixth International Conference on Logic Programming
19-23 June 1989 - Lisboa, Portugal
The Association of Logic Programming is sponsoring the 6th International
Conference on Logic Programming. Previous ICLP meetings were held in
Marseille, Uppsala, London, Melbourne, and, joint with the Symposium on
Logic Programming, in Seattle.
Programme Chairman Conference Chairmen
Giorgio Levi, ICLP'89 Antonio Porto and Luis Moniz Pereira
Dipartimento di Informatica Departamento de Informatica
Universita' di Pisa Universidade Nova de Lisboa
Corso Italia, 40 Quinta da Torre
56100 Pisa 2825 Monte de Caparica
ITALY PORTUGAL
Conference Topics
Authors are invited to submit papers on all aspects of Logic Programming,
including, but not restricted to:
- Applications
- Architectures
- Complexity
- Concurrent Languages
- Constraint Languages
- Deductive Databases
- Higher-order Languages and Extensions
- Language Issues
- Program Development Tools and Methodology
- Relations to other Computational Models
- Relations with Artificial Intelligence
- Sequential and Parallel Implementations
- Theory and Foundations
Dates
Submission deadline: December 1, 1988
Notification of acceptance/rejection: March 1, 1989
Camera-ready copies due: April 1, 1989
Paper Submission
Submit five copies of manuscripts to the ICLP-89 Programme Chairman by
December 1, 1988. Papers are restricted to 4,000 words (12-14 double
spaced pages). Papers overlength will not be considered.
Each paper must contain a 200-250 word abstract, and must be written and
presented in English.
Papers should not be simultaneously submitted for publication elsewhere.
Important: Authors are requested to use first class/ex-press mail or
private carriers for their sub-missions: do not use printed-matter mail.
Please notify your submission by e_mail, telex or fax to M. Martelli:
e_mail: martelli@icnucevm.bitnet
telex: 500371 CNUCE I
fax: +39 - 50 - 576751
A limited number of ALP bursaries may be available to assist authors of
accepted papers who would not otherwise be able to attend the Conference.
Authors that have no access to copy machines can send a single copy.
Programme Committee
G. Levi
Univ. of Pisa, Pisa, Italy (Chairman)
K. R. Apt
CWI, Amsterdam, The Netherlands, and
Univ. of Texas at Austin, Austin, TX, USA
M. Bruynooghe
Katholieke Universiteit Leuven, Heverlee,
Belgium
T. Chikayama
ICOT,Tokyo, Japan
W.F. Clocksin
Univ. of Cambridge, Cambridge, UK
A. Colmerauer
Marseille,France
J. Connery
Univ.of Oregon, Eugene, OR, USA
M. Dincbas
ECRC, Munich, F.R. Germany
M. Genesereth
Standford Univ., Standford, CA, USA
M. Hermenegildo
MCC, Austin, TX, USA
C.J. Hogger
Imperial College,London ,UK
F. Kluzniak
Warszawa University, Warszawa, Poland
M.J. Maher
IBM-T.J. Watson Research Center, NY, USA
J. Maluszynski
Univ.of Linkoping, Linkoping, Sweden, and
Univ. of Utah, Salt Lake City, UT, USA
M. Martelli
CNUCE, Pisa, Italy
Y. Matsumoto
Kyoto University, Kyoto, Japan
F. G. McCabe
Imperial College, London, England
D. Miller
Univ. of Pennsylvania, Philadelphia, PA, USA
J. Minker
Univ. of Maryland, College Park, MD, USA
G. Mints
Estonian Academy of Science, Tullinn, USSR
L. Naish
Melbourne Univ., Melbourne, Australia
R. Overbeek
Argonne National Laboratory, Argonne, IL, USA
L. M. Pereira
Univ. of Lisboa, Lisboa, Portugal
A. Porto
Univ. of Lisboa, Lisboa, Portugal
T. O. Przymusinski
Univ. of Texas at El Paso, El Paso, TX, USA
Y. Sagiv
Hebrew University, Jerusalem, Israel
E. Y. Shapiro
Weizmann Institute of Science, Rehovot, Israel
O. Shmueli
Israel Institute of Technology, Haifa, Israel
C. Zaniolo
MCC, Austin, TX, USA
∂18-Oct-88 0830 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu WOBCATS
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Oct 88 08:29:58 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA11315; Tue, 18 Oct 88 08:29:44 PDT
Message-Id: <8810181529.AA11315@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 18 Oct 88 08:30:19 PDT
Received: by BYUADMIN (Mailer X2.00) id 7472; Tue, 18 Oct 88 09:28:18 MDT
Date: Tue, 18 Oct 88 10:15:58 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Richard Anderson <anderson%JUNE.CS.WASHINGTON.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Richard Anderson <anderson%JUNE.CS.WASHINGTON.EDU@Forsythe.Stanford.EDU>
Subject: WOBCATS
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
W O B C A T S
Washington, Oregon, British Columbia, and Alberta Theory Seminar
Friday, November 11, 1988
University of Washington, Seattle, Washington
Schedule
11:00 Larry Ruzzo, University of Washington
"New bounds on universal traversal sequences"
12:00 LUNCH
1:00 Problem Session
1:30 Nick Pippenger, University of British Columbia
"Almost optimal self-correcting networks for almost
all boolean functions"
2:30 BREAK
2:45 Mike Luby, University of Toronto
"Removing randomness in parallel computation without a
processor penalty"
The talks will be held in room 323 of Seig Hall. Seig Hall is located at
the center of the University of Washington campus, next to the large
hole in the ground. Seig Hall is the ugly building that looks like
a Howard Johnsons.
For more information, contact
Richard Anderson 206-543-4305, anderson@june.cs.washington.edu
Paul Beame 206-543-5114, beame@june.cs.washington.edu
∂18-Oct-88 0835 DELAGI@SUMEX-AIM.Stanford.EDU [Bart Miller <bart@SPEEDY.CS.WISC.EDU>:]
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Oct 88 08:35:45 PDT
Date: Tue, 18 Oct 88 08:29:27 PDT
From: Bruce A. Delagi <DELAGI@SUMEX-AIM.Stanford.EDU>
Subject: [Bart Miller <bart@SPEEDY.CS.WISC.EDU>:]
To: aap@SUMEX-AIM.Stanford.EDU
Message-ID: <12439426288.34.DELAGI@SUMEX-AIM.Stanford.EDU>
Return-Path: <fpst@HUBCAP.CLEMSON.EDU>
Received: from RELAY.CS.NET by SUMEX-AIM.Stanford.EDU with TCP; Mon, 17 Oct 88 13:24:10 PDT
Received: from hubcap.clemson.edu by RELAY.CS.NET id aa07098; 17 Oct 88 8:36 EDT
Received: by hubcap.clemson.edu; Mon, 17 Oct 88 08:12:19 edt
Date: Mon, 17 Oct 88 08:12:19 edt
Message-Id: <8810171212.AA10073@hubcap.clemson.edu>
To: DELAGI%SUMEX-AIM.Stanford.EDU@RELAY.CS.NET,
coraki!pratt%Sun.COM@RELAY.CS.NET, cvb%daresbury.ac.uk@RELAY.CS.NET,
develo%waikato.ac.nz@RELAY.CS.NET, dwk%cs.tufts.edu@RELAY.CS.NET,
gopalakr%enuxha.asu.edu@RELAY.CS.NET,
hcube-users%hamlet.caltech.edu@RELAY.CS.NET,
hcube-users%mtu.edu@RELAY.CS.NET, scherrer%lovada.dec.com@RELAY.CS.NET
Newsgroups: comp.parallel
From: Bart Miller <bart@SPEEDY.CS.WISC.EDU>
Subject: Proceedings of Workshop on Parallel & Distr Debugging
Keywords: debugging workshop
Approved: parallel@hubcap.clemson.edu
The SIGPLAN/SIGOPS Workshop on Parallel and Distributed Debugging took place
in May in Madison, Wisconsin. There were 23 papers presented and two panel
sessions. A copy of the proceedings (papers and abstracts) was distributed
to each attendee.
I've received many queries about the availability of the Debugging Workshop
proceedings, so I thought I would post the latest news.
SIGPLAN Notices will be publishing the proceedings in the January issue. All
SIGPLAN member should receive a copy. The published proceedings will contain
the 23 papers and session summaries of each paper and panel session. The
session summaries will also appear in the upcoming issue of Operating Systems
Review (the SIGOPS publication).
The first Workshop produced a lot of good discussion and interaction, and the
consensus was that there should be a follow-up meeting. Plans are to have
the 2nd Workshop on Parallel and Distributed Debugging in May 1990 (two years
between meetings seems like the right amount of time). Any ideas that you
might have for the 2nd meeting are welcome.
--bart miller
uw-madison cs dept
bart@cs.wisc.edu
...!uwvax!bart
-------
∂18-Oct-88 0839 THAPAR@SUMEX-AIM.Stanford.EDU debugging workshop
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Oct 88 08:39:09 PDT
Date: Tue, 18 Oct 88 08:33:11 PDT
From: Manu Thapar <THAPAR@SUMEX-AIM.Stanford.EDU>
Subject: debugging workshop
To: delagi@SUMEX-AIM.Stanford.EDU, aap@SUMEX-AIM.Stanford.EDU
Message-ID: <12439426968.11.THAPAR@SUMEX-AIM.Stanford.EDU>
I have the proceedings of this workshop if anyone is interested.
Manu
-------
∂18-Oct-88 0850 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu AMAST -- Call for Abstracts
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Oct 88 08:50:34 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA12040; Tue, 18 Oct 88 08:50:29 PDT
Message-Id: <8810181550.AA12040@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 18 Oct 88 08:51:05 PDT
Received: by BYUADMIN (Mailer X2.00) id 7843; Tue, 18 Oct 88 09:48:57 MDT
Date: Tue, 18 Oct 88 10:18:34 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Chic Rattray <cr%CS.STIR.AC.UK@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Chic Rattray <cr%CS.STIR.AC.UK@Forsythe.Stanford.EDU>
Subject: AMAST -- Call for Abstracts
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
------------------------------------------------------------------------
CALL FOR ABSTRACTS
International Conference on
Algebraic Methodology And Software Technology, AMAST
Iowa City, Iowa, May 22-24, 1989
The goal of the conference is to consolidate the trend of using
algebraic methodology as a foundation for software technology
showing that universal algebra provides a practical mathematical
alternative to ad hoc approaches used in software development.
Both academia and industry are the beneficiary of such a formal
foundation.
In order to achieve this goal, we plan to bring together leading
researchers in mathematics and computer science on a common plat-
form so that algebraic methodologies that can be used as a viable
alternative to ad hoc approaches for software development can be
identified and the appropriateness of such alternatives in view
of actual implementations can be discussed. The invited speakers
include:
Constable, R., Cornnell University, Ithaca, New York, USA
Lawvere, W. F., State University of New York at Buffalo, USA
Meseguer, J., SRI International, USA
Nivat, M., The University of Paris, France
Wagner, E., IBM Thomas J. Watson Reserach Center, USA
Talks reporting research in algebra suitable as a foundation for
software technology as well as software technologies developed by
means of algebraic methodologies are welcome. We invite you to
submit a two page abstract (including a few citations of relevant
work) of your talk to the address
The submissions must be received by February 1, 1989 and the
notifications of acceptance will be sent by March 15, 1989. The
authors should include a return postal address and an electronic
mail address if it is available.
A special issue of the journal ``Theoretical Computer Science''
will be dedicated to this conference and each participant will be
invited to submit a full paper for publication.
The program committee consists of:
Arthur Fleck, University of Iowa, USA
Dan Ionescu, University of Ottawa, Canada
William A. Kirk, University of Iowa, USA
Eugene Madison, University of Iowa, USA
Michael Main, University of Colorado, USA
Michael Mislove, Tulane University, USA
Monagur Muralidharan, University of Iowa, USA
George Nelson, University of Iowa, USA
Teodor Rus, University of Iowa, USA
David Schmidt, Kansas State University, USA
Further information can be obtained from:
In Canada: | In Europe: | In U.S.A:
=======================|========================|=====================
Prof. Dan Ionescu | Prof. Maurice Nivat | Prof. Eugene Madison
University of Ottawa & | Universit',e- Paris | Mathematics
Dept. of Elec. Eng.& 2,| Place Jussieu | Prof. Teodor Rus
770 King Edward, OTTAWA| 75005 Paris, France | Computer Science
Ont. Canada K1N 6N5 | Phone: (1) 43 25 98 74 | The University of Io
Phone: (613)-564-2211 | | City, IA 52242, U.S.
e-mail: | | Phone: (319)-335-069
diopb@uottawa.BITNET | | e-mail:
| | rus@herky.cs.uiowa
======================================================================
The local arrangements chairmen are:
Teodor Rus and Monagur N. Muralidharan
Department of Computer Science
University of Iowa
Iowa City, IA 52242
∂18-Oct-88 0912 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu Re: Tenured Faculty Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Oct 88 09:12:15 PDT
Received: from Pescadero by SCORE.STANFORD.EDU with TCP; Tue 18 Oct 88 09:06:35-PDT
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA10345; Tue, 18 Oct 88 09:12:06 PDT
Date: Tue, 18 Oct 88 09:12:06 PDT
From: "David Cheriton" <cheriton@pescadero.stanford.edu>
Message-Id: <8810181612.AA10345@Pescadero>
To: chandler@polya.Stanford.EDU, faculty@score.Stanford.EDU
Subject: Re: Tenured Faculty Meeting
In-Reply-To: <CMM.0.87.593104389.chandler@polya.stanford.edu> from
"Joyce R. Chandler" <chandler@polya> on Mon, 17 Oct 1988 8:13:09 PDT
I have a class from 2:45 pm - 4:00 pm. conflicting with the faculty meeting.
I bother everyone on this because I think there is some issue about the use
of this time slot.
At a faculty meeting several years ago, it was decided to officially allow
classes to be scheduled at this time, although previously it was reserved
for faculty meetings. The argument was: There are too few TV rooms and
75 minute lecture times to sacrifice this whole time slot for the
occassional meeting.
I think the idea of reserving a time for meetings is a good one, but let's
find a time that has less teaching demand. Is Tues at 4 pm a possibility
with the demise of the CSD Colloq? Or how about a early morning time.
I would prefer, and I think the students would too, the occassional meeting
at an unpopular hour, rather than teaching at an unpopular hour or having
yet more classes that time conflict.
David C.
∂18-Oct-88 1036 @polya.Stanford.EDU:chomicki@brillig.umd.edu Rita G. Minker
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Oct 88 10:36:35 PDT
Received: from brillig.umd.edu by polya.Stanford.EDU (5.59/25-eef) id AA17167; Tue, 18 Oct 88 10:32:59 PDT
Received: by brillig.umd.edu (5.58/4.7)
id AA16769; Tue, 18 Oct 88 13:31:35 EDT
Date: Tue, 18 Oct 88 13:31:35 EDT
From: Jan Chomicki <chomicki@brillig.umd.edu>
Message-Id: <8810181731.AA16769@brillig.umd.edu>
To: nail@polya.stanford.edu
Subject: Rita G. Minker
Rita G. Minker
April 28, 1927 - October 11, 1988
Rita G. Minker, early worker in the field of computer
programming, died on October 11, 1988 of cancer at the age
of 61. Mrs. Minker received a B.S. degree with High Honors
in Mathematics from Douglass College in 1948 and a M.A.
degree in Mathematics from the University of Wisconsin in
1950.
In the summer of 1950 Mrs. Minker started to work at
the prestigious Bell Telephone Laboratories in Murray Hill,
New Jersey. She programmed network problems for one of the
early digital computers, the Bell Relay Machine. She was
among the first computer programmers in the United States.
On June 24, 1951 she married Jack Minker, who she had met at
the University of Wisconsin. The couple moved to Buffalo,
New York, where Mrs. Minker was employed as a mathematician
at the Cornell Aeronautical Laboratories. She worked on
electronic analog computers on which she simulated the per-
formance of missile systems. In 1952 she was hired by RCA
in Camden, New Jersey and became the second computer pro-
grammer, and the first woman programmer to work at that com-
pany. She programmed the Bizmac, RCA's first computer.
In 1953 Mrs. Minker took time off from the computing
profession to raise a family. In April 1964, when her two
children were enrolled in school, Mrs. Minker returned to
work as a mathematician and computer programmer in the newly
formed Division of Computer Research and Technology (DCRT)
at the National Institutes of Health (NIH)in Bethesda, Mary-
land. She was one of the charter members of this division,
formed to service the computer needs of medical researchers
at the NIH. Although the computing profession had made sig-
nificant progress during the time she was raising her fam-
ily, Mrs. Minker was able to rapidly learn the new technol-
ogy and recapture her skills as a programmer and mathemati-
cian. She served as Head, Training Unit in DCRT from 1968 -
1975, and instituted training courses to permit medical
researchers to learn how to program and work with computers
and become familiar with statistical methods. In 1975,
after having built-up the Training Division, she joined the
Statistical Software Section, Laboratory of Statistical and
Mathematical Methodology of the DCRT. She was able to par-
ticipate and assist medical researchers with their program-
ming and statistics problems. She was also in charge of
consulting on and maintaining SPSS, a major statistical
package.
Mrs. Minker was co-author of a number of medical jour-
nal articles on the schistosomyacin disease and was ack-
nowledged for her assistance in numerous medical journal
articles. Together with her husband, she published an arti-
cle in the Annals of the History of Computing, which traced
the historical developments in the optimization of boolean
expressions and related problems.
Mrs. Minker had a long bout with cancer. She first
contracted breast cancer in 1975. The disease reoccurred in
1985. Because of her illness she was forced to retire from
the government in April 1988, exactly 24 years after she was
hired at the NIH. Mrs. Minker is survived by her son,
Michael Saul Minker who resides with his wife Katharine in
Chevy Chase, Maryland; by her daughter, Sally Anne Minker,
who lives in Bethesda, Maryland; by her husband, Jack
Minker, of Bethesda, Maryland; her father, Louis H. Goldberg
and step-mother, Anna Goldberg of North Miami Beach,
Florida; and brother, Sanford H. Goldberg of West Orange,
New Jersey.
Funeral services will be held at:
10:00AM Thursday, October 13, 1988
Congregation Beth El
8215 Old Georgetown Road
Bethesda, Maryland
Contributions may be made to the American Cancer Society in
her memory.
The family will receive condolence calls during the
period October 13, 1988 through the evening of October 18,
1988 at the home of:
Jack Minker
6913 Millwood Road
Bethesda, Maryland 20817
If you wish to offer condolences by e-mail, Professor Minker
can be reached at <minker@mimsy.umd.edu>.
∂18-Oct-88 1722 hoffman@csli.Stanford.EDU Symbolic Systems Forum Oct. 21 (Friday)
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Oct 88 17:22:30 PDT
Received: by csli.Stanford.EDU (4.0/4.7); Tue, 18 Oct 88 17:23:32 PDT
Date: Tue 18 Oct 88 17:23:30-PDT
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: Symbolic Systems Forum Oct. 21 (Friday)
To: ssp-faculty@csli.Stanford.EDU, ssp-students@csli.Stanford.EDU,
ssp-forum@csli.Stanford.EDU
Message-Id: <593223810.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
The Symbolic Systems Forum this Friday will be John McCarthy speaking
on Formalizing Common Sense Knoweldge and Reasoning in Mathematical
Logic. As always, the Forum will be held at 3:15 in building 60 in
the quad. However, as it's more likely to have a large crowd, the
Forum will meet in the large lecture hall right next to the entrances
to the building. John McCarthy is one of the cofounders of Artificial
Intelligence. He has worked on problems associated with the logic approach to
AI for 30 years and will discuss what has been accomplished and what seem to be
the next problems. This involves representing by mathematical logical
sentences what a computer program should know about the common sense world in
general and about specific situations. What it can infer about what actions
will achieve its goals is determined by logical inference including both
logical deduction and formalized nonmonotonic reasoning.
Next week, Oct. 28, Solomon Feferman will speak on Turing's Oracle.
-------
∂18-Oct-88 2146 CL-Cleanup-mailer DRAFT Issue: TEST-NOT-IF-NOT (Version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 18 Oct 88 21:46:16 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA06569g; Tue, 18 Oct 88 21:46:10 PDT
Received: by bhopal id AA03592g; Tue, 18 Oct 88 21:44:37 PDT
Date: Tue, 18 Oct 88 21:44:37 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810190444.AA03592@bhopal>
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: cl-cleanup@sail.stanford.edu's message of 8 Oct 88 22:07 PDT <881008-220711-2583@Xerox>
Subject: DRAFT Issue: TEST-NOT-IF-NOT (Version 2)
Several others have already expressed my sentiments towards this proposal --
that it would have been a nice idea five years ago, but is a gratuitous
incompatibility now. "Gratuitous", because lots of uses will have to
worry about whether or not their code needs to be massaged, and the
_payback_ to them will be insignificant.
It would certainly be acceptable to "deprecate" the use of any ...-IF-NOT
function, and of the :TEST-NOT keyword argument; this ought to be an
editorial discretion, rather than requireing lots of cl-cleanup time.
-- JonL --
∂19-Oct-88 1219 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Wilkinson Fellowship at Argonne Nat Lab
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Oct 88 12:19:15 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA11472; Wed, 19 Oct 88 12:19:09 PDT
Message-Id: <8810191919.AA11472@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 19 Oct 88 12:19:42 PDT
Received: by BYUADMIN (Mailer X2.00) id 7222; Wed, 19 Oct 88 13:17:37 MDT
Date: Wed, 19 Oct 88 14:04:11 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
dongarra%antares@ANL-MCS.ARPA
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: dongarra%antares@ANL-MCS.ARPA
Subject: Wilkinson Fellowship at Argonne Nat Lab
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
WILKINSON FELLOWSHIP IN COMPUTATIONAL MATHEMATICS
Mathematics and Computer Science Division
Argonne National Laboratory
Argonne National Laboratory is seeking outstanding
candidates in the general area of computational mathematics
to fill the newly created J.H. Wilkinson Fellowship in
Computational Mathematics.
This fellowship was created in memory of Dr. James
Hardy Wilkinson, F.R.S., who for many years had a close
association with the Mathematics and Computer Science
Division at Argonne, where he acted as a consultant and
guiding spirit for such efforts as the EISPACK and LINPACK
projects.
The J.H. Wilkinson Fellowship is intended to encourage
young scientists who are actively engaged in state-of-the-
art research in computational mathematics-including, but not
limited to, the development and implementation of numerical
algorithms for linear algebra. The candidate must have
earned (or be about to earn) a Ph.D. degree or the
equivalent during the past three years and should have a
strong background in numerical computation. The candidate
should also be interested in expanding into the area of
advanced computing research. Argonne's Mathematics and
Computer Science Division has strong programs in
computational mathematics and advanced computing, as well as
in software engineering and applied analysis.
This one-year appointment includes a competitive
salary, moving expenses, and a generous professional travel
allotment. Applications from qualified candidates, as well
as nominations for the position of Wilkinson Fellow, should
be addressed to Rosalie L. Bottino, Box D-MCS-WF89-83,
Employment and Placement, 9700 South Cass Ave., Argonne
National Laboratory, Argonne, Illinois 60439-4844.
Applications should include a resume and a statement of
research goals, and the names of three references. The
closing date for applications is December 1, 1988. The
applications will be reviewed during January 1989, by an
international selection committee. The position will
commence during 1989.
Further inquiries can be made by calling 312-972-7163
or by sending electronic mail to dongarra@anl-mcs.arpa.
Argonne is an affirmative action/equal opportunity
employer.
∂19-Oct-88 1350 barwise@russell.Stanford.EDU A graduate program in Philosophy and SS
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Oct 88 13:50:12 PDT
Received: from localhost by russell.Stanford.EDU (4.0/4.7); Wed, 19 Oct 88 13:51:21 PDT
To: ssp-faculty@russell.Stanford.EDU
Subject: A graduate program in Philosophy and SS
Date: Wed, 19 Oct 88 13:50:28 PDT
From: Jon Barwise <barwise@russell.Stanford.EDU>
\documentstyle{article}
\begin{document}
The following Special Program in Philosophy and Symbolic Systems has
been approved by the philosophy department. It is a Ph.D. program in
philosophy. It is continguent on finding some way to admit and
support the students that does not impinge adversely on the existing
philosophy graduate programs.
{\it Prerequistes:} Ideally, students admitted to the program will
have covered the equivalent of the core of the undergraduate SSP
requirements. This involves courses in philosophy, logic, AI,
cognitive science, and linguistics. The graduate program is designed
with this background in mind. Students admitted to the program, but
missing part of this background might well need to take additional
course work to that described below.
{\it Course of study:} The program would consist of two years of
courses, and two years of dissertation work.
Years 1 and 2: Students would be required to take the following
courses:
\begin{enumerate}
\item Philosophy courses: six courses
\begin{enumerate}
\item The philosophy core seminar in
metaphysics and epistemology: Philosophy 280.
\item The philosophy core seminar in philosophy of language: Philosophy 281.
\item One course in the history of modern philosophy.
\item Two quarters of graduate graduate logic courses from among
Philosophy 390A, 391A, 392A, 393A.
\item At least additional seminar in the general area of symbolic
systems: for example, Phil 289, 326, 396, etc.
\end{enumerate}
\item Cognitive Science and Computer science courses: five courses
\begin{enumerate}
\item Cognition (Psych 205)
\item One or two additional courses in cognitive psychology
\item Two or three graduate courses in computer science, at least
one in AI and one in theory.
\end{enumerate}
\item Linguistics and computational linguistics: three courses
\begin{enumerate}
\item Graduate courses that focus on two of the following areas:
syntax of natural language, semantics of natural language,
pragmatics of natural language
\item One graduate course in computational linguistics, typically
Linguistics 227.
\end{enumerate}
\item At least two additional graduate seminars, at a more advanced
level, in the general area of the program, independent of
department. These would typically be in the area of the
student's proposed dissertation project.
\end{enumerate}
Year 3: The requirements for this year would be the same as for other
third year graduate students in philosophy: come up with a
dissertation proposal and a dissertation committee. The latter would
be required to have at least one member of the philosophy department
and one member of the Symbolic Systems Program outside the philosophy
department.
Year 4: Again, the requirements would be the same as for the other
graduate students of the department: a department oral on an initial
draft of part of the dissertation, and a University Oral when the
dissertation is essentially complete.
\end{letter}
\end{document}
∂19-Oct-88 1352 barwise@russell.Stanford.EDU A graduate program in Philosophy and SS
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Oct 88 13:52:32 PDT
Received: from localhost by russell.Stanford.EDU (4.0/4.7); Wed, 19 Oct 88 13:53:33 PDT
To: ssp-faculty@russell.Stanford.EDU
Subject: A graduate program in Philosophy and SS
Date: Wed, 19 Oct 88 13:53:31 PDT
From: Jon Barwise <barwise@russell.Stanford.EDU>
\documentstyle{article}
\begin{document}
The following Special Program in Philosophy and Symbolic Systems has
been approved by the philosophy department. It is a Ph.D. program in
philosophy. It is continguent on finding some way to admit and
support the students that does not impinge adversely on the existing
philosophy graduate programs.
{\it Prerequistes:} Ideally, students admitted to the program will
have covered the equivalent of the core of the undergraduate SSP
requirements. This involves courses in philosophy, logic, AI,
cognitive science, and linguistics. The graduate program is designed
with this background in mind. Students admitted to the program, but
missing part of this background might well need to take additional
course work to that described below.
{\it Course of study:} The program would consist of two years of
courses, and two years of dissertation work.
Years 1 and 2: Students would be required to take the following
courses:
\begin{enumerate}
\item Philosophy courses: six courses
\begin{enumerate}
\item The philosophy core seminar in
metaphysics and epistemology: Philosophy 280.
\item The philosophy core seminar in philosophy of language: Philosophy 281.
\item One course in the history of modern philosophy.
\item Two quarters of graduate graduate logic courses from among
Philosophy 390A, 391A, 392A, 393A.
\item At least additional seminar in the general area of symbolic
systems: for example, Phil 289, 326, 396, etc.
\end{enumerate}
\item Cognitive Science and Computer science courses: five courses
\begin{enumerate}
\item Cognition (Psych 205)
\item One or two additional courses in cognitive psychology
\item Two or three graduate courses in computer science, at least
one in AI and one in theory.
\end{enumerate}
\item Linguistics and computational linguistics: three courses
\begin{enumerate}
\item Graduate courses that focus on two of the following areas:
syntax of natural language, semantics of natural language,
pragmatics of natural language
\item One graduate course in computational linguistics, typically
Linguistics 227.
\end{enumerate}
\item At least two additional graduate seminars, at a more advanced
level, in the general area of the program, independent of
department. These would typically be in the area of the
student's proposed dissertation project.
\end{enumerate}
Year 3: The requirements for this year would be the same as for other
third year graduate students in philosophy: come up with a
dissertation proposal and a dissertation committee. The latter would
be required to have at least one member of the philosophy department
and one member of the Symbolic Systems Program outside the philosophy
department.
Year 4: Again, the requirements would be the same as for the other
graduate students of the department: a department oral on an initial
draft of part of the dissertation, and a University Oral when the
dissertation is essentially complete.
\end{letter}
\end{document}
∂19-Oct-88 1407 ULLMAN@Score.Stanford.EDU house available
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Oct 88 14:06:52 PDT
Date: Wed 19 Oct 88 14:00:49-PDT
From: Jeffrey D. Ullman <ULLMAN@Score.Stanford.EDU>
Subject: house available
To: faculty@Score.Stanford.EDU
Message-ID: <12439748757.20.ULLMAN@Score.Stanford.EDU>
It looks like I'll be going on sabbatical approximately Feb-June, 1989,
and I would like to rent my house on campus. Does anybody have a
visitor who needs a large (4-6 bedrooms, depending on how you count)
house?
---jeff
-------
∂19-Oct-88 1823 emma@csli.Stanford.EDU CSLI Calendar, October 20, 4:5
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Oct 88 18:23:26 PDT
Received: by csli.Stanford.EDU (4.0/4.7); Wed, 19 Oct 88 17:31:00 PDT
Date: Wed, 19 Oct 88 17:31:00 PDT
From: emma@csli.Stanford.EDU (Emma Pease)
To: friends@csli.Stanford.EDU
Subject: CSLI Calendar, October 20, 4:5
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
20 October 1988 Stanford Vol. 4, No. 5
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 20 October 1988
12 noon TINLab
Cordura Hall What IS Situated Language
Conference Room by John Perry
(john@csli.stanford.edu)
2:15 p.m. CSLI Seminar
Cordura Hall Psychological Processes
Conference Room Herb Clark
(herb@psych.stanford.edu)
Abstract below
3:45 p.m. Tea
Ventura Hall
4:00 p.m. STASS Seminar
Cordura Hall Points of View in Situation Semantics
Conference Room Yasuhiro Katagiri
Nippon Telegraph and Telephone Corp.
Abstract in last week's Calendar
____________
CSLI ACTIVITIES FOR NEXT THURSDAY, 27 October 1988
12 noon TINLecture
Cordura Hall Chaos
Conference Room Bernardo Huberman
(huberman.pa@xerox.com)
Abstract below
2:15 p.m. CSLI Seminar
Cordura Hall Early AI Research on Local Pragmatics
Conference Room Jerry Hobbs
(hobbs@warbucks.ai.sri.com)
Abstract below
3:45 p.m. Tea
Ventura Hall
____________
THIS WEEK'S CSLI SEMINAR
The Resolution Problem for Natural-Language Processing
Week 4: Psychological Processes
Herb Clark
(herb@psych.stanford.edu)
20 October
I will review part of what is known about the process of resolving
ambiguities and indeterminacies from work in psychology. Last week I
took up, among other things, the issues of automaticity and modularity
in resolving structural ambiguities--that is, ambiguous words,
attachment ambiguities, and other local parsing ambiguities. The
question is, how are these ambiguities resolved so quickly and
apparently automatically on the basis of lexical, syntactic, semantic,
and pragmatic information, and what does this say about the process of
understanding in general? This week I will take up the more pragmatic
issues in resolution, such as how people resolve references,
illocutionary force, and implicatures, and how speakers and listeners
manage to do this collectively.
____________
NEXT WEEK'S TINLECTURE
Chaos
Bernardo Huberman
Xerox PARC
and
Applied Physics Department, Stanford University
(huberman.pa@xerox.com)
October 27
Recent developments in dynamical systems theory have led to a
reappraisal of our understanding of determinism and the origin of
noise in many physical systems. In particular, it has been established
that certain deterministic systems with few degrees of freedom can
exhibit random behavior that is analogous to that produced by the
tossing of a coin.
This talk will provide an introduction to the field of
deterministic chaos. It will also elucidate the notion of
universality, and its implications for the application of chaos theory
to many fields of science.
____________
NEXT WEEK'S CSLI SEMINAR
The Resolution Problem for Natural-Language Processing
Week 5: Early AI Research on Local Pragmatics
Jerry Hobbs
(hobbs@warbucks.ai.sri.com)
October 27
AI researchers have been grappling with problems in local pragmatics,
or the resolution problem, for at least the last fifteen years. We
will discuss Rieger's work on several of these problems, work on the
interpretation of nominal compounds, including that of Finin, and
early and more recent work on pronoun resolution, syntactic ambiguity,
metonymy, and quantifier scope ambiguity that has been in the same
spirit. All of this work has been characterized by attempts to aim
toward efficient and effective heuristics that use world knowledge in
a limited enough way to make the approach feasible. The shortcomings
of this family of approaches will also be discussed.
____________
SYMBOLIC SYSTEMS FORUM
Formalizing Commonsense Knowledge and Reasoning
in Mathematical Logic
John McCarthy
Friday, 21 October, 3:15
Bldg. 60
This Friday John McCarthy will be speaking on formalizing commonsense
knowledge and reasoning in mathematical logic. He is one of the
cofounders of artificial intelligence. He has worked on problems
associated with the logic approach to AI for thirty years and will
discuss what has been accomplished and what seem to be the next
problems. This involves representing by mathematical logical
sentences what a computer program should know about the commonsense
world in general and about specific situations. What it can infer
about what actions will achieve its goals is determined by logical
inference including both logical deduction and formalized nonmonotonic
reasoning.
As always, the Forum will be held at 3:15 in building 60. However,
because we are expecting a large crowd, it will meet in the lecture
hall right next to the entrances to the building instead of room 62N.
--------------
CSLI TALK
Nonstandard Normalization
Shigeki Goto
Nippon Telegraph and Telephone Corporation
Monday, 31 October, 2:30
Cordura Conference Room 100
It is well known that formal proof systems can serve as programming
languages. A proof that describes an algorithm can be executed by
Prawitz's normalization procedure. This talk extends the
computational use of proofs to realize a lazy computation formally.
It enables computation of a proof over stream objects (infinitely long
lists) as in Concurrent Prolog.
To deal with infinitely long objects, we will extend the number
theory to incorporate infinite numbers. This is an application of
nonstandard analysis to computer programs. We will show that the rule
of mathematical induction can be extended to cover infinite numbers
with appropriate computational meaning.
The method of introducing nonstandard integers was independently
proposed by the speaker (Goto) and Professor Per Martin-Lof at
Stockholm University. He will briefly discuss Martin-Lof's extension
of his constructive type theory.
∂20-Oct-88 0958 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Thinking Machines
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Oct 88 09:58:34 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 20 Oct 88 09:57:02-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA26763; Thu, 20 Oct 88 09:57:24 PDT
Date: Thu, 20 Oct 1988 9:57:21 PDT
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: wiederhold@sumex-aim, tom@score, engelmore@sumex-aim, lam@mojave,
jle@pescadero
Cc: faculty@score
Subject: Thinking Machines
Message-Id: <CMM.0.87.593369841.chandler@polya.stanford.edu>
A reminder.....Marvin Denicoff (ex of ONR and now of Thinking Machines) and
someone from Thinking Machines will visit us tomorrow, October 21 to make a
presentation about the Connection Machine. We will meet at 3:00 in room 352,
Margaret Jacks Hall.
∂20-Oct-88 1244 hoffman@csli.Stanford.EDU Symbolic Systems Forum Oct. 28
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Oct 88 12:44:31 PDT
Received: by csli.Stanford.EDU (4.0/4.7); Thu, 20 Oct 88 12:45:26 PDT
Date: Thu 20 Oct 88 12:45:25-PDT
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: Symbolic Systems Forum Oct. 28
To: ssp-faculty@csli.Stanford.EDU, ssp-students@csli.Stanford.EDU,
ssp-forum@csli.Stanford.EDU, forum-faculty@csli.Stanford.EDU
Message-Id: <593379925.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Unfortunately, the Kant Lectures (which I was going to announce anyway) have
been rescheduled so that the first lecture happens on Oct. 28, 3:15 pm. Thus,
Solomon Feferman will not speak, but will speak at an (as yet) unscheduled
time in Winter Quarter. We will not have a forum on that day as everyone
(including me) will be attending the Kant Lecture. The Kant Lectures
this year are given by David Lewis, under the General Title "Parts of
Classes."
The Schedule is as follows:
Oct. 28 3:15: "What Are the Parts of Classes?"
Oct. 31 4:15: "The Trouble with Classes"
Nov. 4 3:15: "Mereologized Arithmetic"
(discussion following, extending to 6PM)
All lectures in Building 420, Room 041
There is also a public lecture by Lewis,
Nov. 1 8PM, "Mill and Milquetoast: On the Disutility and Utility of Toleration"
There is also a problem with the Nov. 4 time, which has not been resolved yet.
-------
∂20-Oct-88 1317 Kay.pa@Xerox.COM Re: SSP-lunch
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Oct 88 13:17:50 PDT
Received: from Xerox.COM by russell.Stanford.EDU (4.0/4.7); Thu, 20 Oct 88 13:18:54 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 20 OCT 88 13:11:56 PDT
Date: 20 Oct 88 13:11 PDT
From: Kay <Kay.pa@Xerox.COM>
Subject: Re: SSP-lunch
In-Reply-To: Helen Nissenbaum <HELEN@CSLI.Stanford.EDU>'s message of Mon,
17 Oct 88 12:07:18 PDT
To: Helen Nissenbaum <HELEN@CSLI.Stanford.EDU>
Cc: ssp-faculty@russell.Stanford.EDU
Message-Id: <881020-131156-4108@Xerox>
I thought I had replied before. Please forgive! I plan to be there.
-- Martin
∂20-Oct-88 1512 hoffman@csli.Stanford.EDU some Symbolic System Forums Announcements
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Oct 88 15:12:30 PDT
Received: by csli.Stanford.EDU (4.0/4.7); Thu, 20 Oct 88 15:03:09 PDT
Date: Thu 20 Oct 88 15:03:08-PDT
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: some Symbolic System Forums Announcements
To: ssp-forum@csli.Stanford.EDU, forum-faculty@csli.Stanford.EDU
Message-Id: <593388188.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Two announcements:
There will be no forum on either Oct. 28 or Nov. 4 because of conflicts with
the Kant Lectures. The titles and place of those lectures reside in an
earlier note.
Professors Jon Barwise and John Etchemendy will be speaking on Nov. 11 on
Logic and Information in Symbolic Systems. Their lecture will be held in
a special class room in Suite Hall (at Stanford.) Then purpose of this is that
Barwise will give a demonstration on the Mac IIs of the special classroom.
The room in Suite Hall is room 026 in Suite Hall, a building which is close to
the other side of Meyer Library from Green Library. Go down the stairs to the
basement and walk along the hallway until you find the room.
Also, the public lecture which Lewis is giving (as opposed to the other) is not
in the same place as the others. The Philosophy Department announcement said
in the basement of the History Building, which probably (but not certainly)
means room 2.
-------
∂20-Oct-88 2352 tah@linz MTC Seminar
Received: from linz.stanford.edu by SAIL.Stanford.EDU with TCP; 20 Oct 88 23:52:28 PDT
Received: by linz.stanford.edu (4.0/SMI-DDN)
id AA22856; Thu, 20 Oct 88 23:46:00 PDT
Message-Id: <8810210646.AA22856@linz.stanford.edu>
To: alur@polya, arean@polya, barwise@russell, bhoward@polya, chavez@sumex-aim,
clt@sail, coraki!pratt@sun.com, crew@polya, devlin@csli, dill@amadeus,
eswolf@polya, fernando@csli, galbiati@polya, grove@polya,
gurevich@polya, herskovits@sumex-aim, hirani@sun.com, howard@polya,
jcm@ra, jmc-lists@sail, kar@polya, kolaitis@polya, lincoln@polya,
lowry@coyote, ma@src.dec.com, martin@polya, mb@jeeves, mcguire@polya,
shankar@score, olthoff@hplabs.hp.com, peters@russell, pieper@geode,
polaschek@sumex-aim, rdz@score, rjw@sail, roach@score, rtc@sail,
sf@csli, traugott@jeeves, val@sail, vardi@polya, vasilis@polya,
weening@gang-of-four, zm@sail, tah@linz
Subject: MTC Seminar
Date: 20 Oct 88 23:45:38 PDT (Thu)
From: Tom Henzinger <tah@linz>
We'll meet again this Friday, Oct. 21, at 12 noon in MJH 301.
We're going to continue to discuss Scott's 1980 paper.
-------
Let me try to pin down last week's insights.
1. What is a suitable *syntax* for a formal system of unary typed functions
with composition?
Answer: + a set of types T
+ a set of variables V
+ a set of function symbols F
+ a type-assigning bijection Var: V -> T
+ a type-assigning function Dom: F -> T
+ a type-assigning function Cod: F -> T
The set of well-formed (i.e., typed) expressions E and substitution as a
partial function Subst: ExE -p-> E is defined as usual.
2. What is a category?
Answer: + a set of objects O
+ a set of morphisms M
+ a function DOM: M -> O
+ a function COD: M -> O
+ a function ID: O -> M
+ a partial function o: MxM -p-> M such that
xoy defined iff COD(x)=DOM(y)
(xoy)oz=xo(yoz) if defined
DOM(xoy)=DOM(x) if defined
COD(xoy)=COD(y) if defined
xoID(COD(x))=x
ID(DOM(x))ox=x
∂21-Oct-88 0002 tah@linz MTC Seminar
Received: from linz.stanford.edu by SAIL.Stanford.EDU with TCP; 21 Oct 88 00:02:49 PDT
Received: by linz.stanford.edu (4.0/SMI-DDN)
id AA22868; Thu, 20 Oct 88 23:56:31 PDT
Message-Id: <8810210656.AA22868@linz.stanford.edu>
To: alur@polya, arean@polya, barwise@russell, bhoward@polya, chavez@sumex-aim,
clt@sail, coraki!pratt@sun.com, crew@polya, devlin@csli, dill@amadeus,
eswolf@polya, fernando@csli, galbiati@polya, grove@polya,
gurevich@polya, herskovits@sumex-aim, hirani@sun.com, howard@polya,
jcm@ra, jmc-lists@sail, kar@polya, kolaitis@polya, lincoln@polya,
lowry@coyote, ma@src.dec.com, martin@polya, mb@jeeves, mcguire@polya,
shankar@score, olthoff@hplabs.hp.com, peters@russell, pieper@geode,
polaschek@sumex-aim, rdz@score, rjw@sail, roach@score, rtc@sail,
sf@csli, traugott@jeeves, val@sail, vardi@polya, vasilis@polya,
weening@gang-of-four, zm@sail, tah@linz
Subject: MTC Seminar
Date: 20 Oct 88 23:56:10 PDT (Thu)
From: Tom Henzinger <tah@linz>
Sorry about the last message. I started to try to work out John's
point at last week's meeting, then decided it's too late, and
accidently sent out the unfinished message. Here's what I really
want to say at this point of the night:
-----------------------------------------------------------------
We'll meet again this Friday, Oct. 21, at 12 noon in MJH 301.
We're going to continue to discuss Scott's 1980 paper.
Last week we identified theories of unary typed functions under
composition (syntax: unary typed expressions + substitution)
with categories, and theories of multi-ary typed functions under
composition (syntax: tuples of typed expressions + substitution)
with categories with finite products.
I suppose the next step is to add application and abstraction,
and to identify such typed lambda-calculi with cartesian-closed
categories.
-- Tom.
P.S.: I've updated last year's LOP mailing list on Polya so that we
can use it for MTC-seminar-related discussions and announcements.
If you send mail to lop@polya it will reach exactly the group of
people who have requested to be kept informed about the seminar.
∂21-Oct-88 0843 emma@russell.Stanford.EDU SSP faculty lunch
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Oct 88 08:43:43 PDT
Received: by russell.Stanford.EDU (4.0/4.7); Fri, 21 Oct 88 08:45:15 PDT
Date: Fri, 21 Oct 88 08:45:15 PDT
From: emma@russell.Stanford.EDU (Emma Pease)
To: ssp-faculty@russell.Stanford.EDU
Subject: SSP faculty lunch
Reminder of the lunch today in Cordura. There will be plenty of good
food, so come if you can.
Emma
ps. This is also a test of the ssp-faculty mailing list.
∂21-Oct-88 0844 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu SIGAL Workshop on Algorithms in Japan -- Call for Papers
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Oct 88 08:44:00 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA18633; Fri, 21 Oct 88 08:43:51 PDT
Message-Id: <8810211543.AA18633@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 21 Oct 88 08:44:14 PDT
Received: by BYUADMIN (Mailer X2.00) id 7094; Fri, 21 Oct 88 09:41:39 MDT
Date: Fri, 21 Oct 88 10:15:42 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Takao Nishizeki <PDA1T6C%JPNTOHOK.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Takao Nishizeki <PDA1T6C%JPNTOHOK.BITNET@forsythe.stanford.edu>
Subject: SIGAL Workshop on Algorithms in Japan -- Call for Papers
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
CALL FOR PAPERS
SIGAL WORKSHOPS ON ALGORITHMS IN JAPAN
Special Interest Group on Algorithms (SIGAL) has been organized in
Information Processing Sociaty of Japan. SIGAL holds a workshop bimonthly.
Usually it is held at the ends of odd-numbered months. A proceedings is
published and distributed at each workshop.
Papers presenting original contributions, tutorials and surveys in the
area of algorithms are being sought. Typical, but not exclusive, topics of inte
rest includes:
(1) combinatorial algorithms on graphs, networks and VLSI,
(2) computational geometry and algebra,
(3) cryptography,
(4) probabilistic and approximation algorithms,
(5) parallel and distributed algorithms,
(6) data structures, and
(7) computational complexity.
Next three workshops are scheduled as follows: November 25, 1988 at the Interna
tional Christian University, Tokyo; January 25-26, 1989 at Tohoku University,
Sendai; and March 22, 1989 in Tokyo.
Any person who have a chance to visit Japan are cordially invited to
present a talk in the workshops. A title with an abstract of at most four
lines should be sent, three months in advance, to:
Professor Takao Nishizeki
Department of Electrical Communications
Tohoku University
Sendai 980
Japan
E-mail: pda1t6c@jpntohok.bitnet
∂21-Oct-88 0844 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Structure in Complexity Theory -- Call for Papers
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Oct 88 08:44:40 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA18641; Fri, 21 Oct 88 08:44:35 PDT
Message-Id: <8810211544.AA18641@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 21 Oct 88 08:45:07 PDT
Received: by BYUADMIN (Mailer X2.00) id 7149; Fri, 21 Oct 88 09:43:14 MDT
Date: Fri, 21 Oct 88 10:18:20 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Steve Mahaney <srm@RESEARCH.ATT.COM>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Steve Mahaney <srm@RESEARCH.ATT.COM>
Subject: Structure in Complexity Theory -- Call for Papers
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
Call for Papers
Structure in Complexity Theory
========= == ========== ======
Fourth Annual Conference
19-22 June 1989
University of Oregon, Eugene, Oregon
The Structure in Complexity Theory Conference focuses on structural
properties of complexity classes and complexity-bounded reducibilities.
Topics of interest include, but are not limited to, the following
issues in complexity theory:
Structure of complexity classes Properties of complete sets
Resource-bounded reducibilities Theory of relativizations
Applications of recursion theory Random and interactive proof systems
Kolmogorov complexity Cryptographic complexity
Applications of finite model theory Independence results
Structural aspects of learning theory Turing machine and circuit complexity
Theory of parallel complexity classes
Original research papers and technical expository talks are sought.
Authors can anticipate 30-45 minutes for presenting research papers,
and 45 minutes for presenting expositiory papers. Authors may state
a time preference, but the final decision will be up to the program committee.
Send 10 copies of an extended abstract or full draft paper to:
Paul Young, Visiting Professor
Department of Computer Sciences
University of Wisconsin
1210 West Dayton Street
Madison, WI 53706, U.S.A.
To be guaranteed consideration, papers must be received in Madison by
December 2, 1988. All accepted papers are to be presented at the conference
by an author of the paper. Notifications of acceptance or rejection will be
mailed by January 31, 1989. Final papers typed on special forms are due
March 17, 1989. Conference Proceedings will be published by the IEEE
Computer Society.
The Program Committee consists of Eric Allender, Jose Balcazar, Neil Immerman,
Tim Long, Janos Simon, Paul Vitanyi, Avi Wigderson, and Paul Young.
Some members of the program committee may present research talks or technical
expository talks providing perspective on their current research programs.
The conference is sponsored by the IEEE Computer Society Technical Committee
for Mathematical Foundations of Computing and the University of Oregon in
cooperation with ACM SIGACT.
Conference Chair Program Chair Local Arrangements
Stephen R. Mahaney Paul Young E. Luks and C. Wilson
Room 2C-454 Computer Science Department Department of Computer
AT&T Bell Laboratories FR-35 and Information Sciences
600 Mountain Ave. University of Washington University of Oregon
Murray Hill, NJ 07974 Seattle, WA 98195 Eugene, OR 97403
∂21-Oct-88 1413 hoffman@csli.Stanford.EDU one correction
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Oct 88 14:13:54 PDT
Received: by csli.Stanford.EDU (4.0/4.7); Fri, 21 Oct 88 14:02:09 PDT
Date: Fri 21 Oct 88 14:02:06-PDT
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: one correction
To: ssp-forum@csli.Stanford.EDU, forum-faculty@csli.Stanford.EDU
Message-Id: <593470926.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
The Nov. 11 Symbolic Systems Forum will take place in Sweet Hall, not
Suite Hall (there is no such place.) As usual, it will be at 3:15. In it,
Jon Barwise and John Etchemendy will speak on Logic and Information in
Symbolic Systems.
-------
∂21-Oct-88 1513 @Score.Stanford.EDU:chandler@polya.Stanford.EDU The Connection Machine
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Oct 88 15:13:49 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 21 Oct 88 15:11:10-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA11067; Fri, 21 Oct 88 15:11:31 PDT
Date: Fri, 21 Oct 1988 15:11:27 PDT
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score
Subject: The Connection Machine
Message-Id: <CMM.0.87.593475087.chandler@polya.stanford.edu>
David Waltz is giving a presentation now on the Connection Machine in MJH-352!!!
∂21-Oct-88 1631 @SUMEX-AIM.Stanford.EDU:mxh@ksl.stanford.edu Frontiers '88 notes
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Oct 88 16:31:03 PDT
Received: from ksl.stanford.edu by SUMEX-AIM.Stanford.EDU with TCP; Fri, 21 Oct 88 16:26:03 PDT
Received: by ksl.stanford.edu (4.0/inc-1.0)
id AA07441; Fri, 21 Oct 88 16:30:18 PDT
Date: Fri, 21 Oct 1988 16:30:17 PDT
From: Max Hailperin <mxh@ksl.stanford.edu>
To: aap@aim.stanford.edu
Subject: Frontiers '88 notes
Message-Id: <CMM.0.88.593479817.mxh@ksl.stanford.edu>
As most of you know, I attended "Frontiers '88: The Second Symposium on the
Frontiers of Massively Parallel Computation" last week. This note is to
pass on pointers to the few interesting presentations.
K(athrine?) Nichols of Apple (but work was done at Bell labs) had some
ideas in the visualization area -- I put her in touch with Bruce. Mostly she
has worked on visual programming rather than instrumentation, but she is
interested in moving into the latter.
Guy Blelloch (Thinking Machines) showed how they translate Sabot's
nested-vectors oriented "Paralation Lisp" into his (Blelloch's) "segmented
scan vectors" model, which is then further translated into unsegmented scans
as described in his faculty-candidate talk here, etc. The example he gave for
Paralation Lisp was quicksort, which very naturally moves from a small number
of large parallel partitions ("intra-something-or-other parallelism") to a
large number of small partitions, in parallel ("inter-whatever-it-was
parallelism"). It looks like a good idea. The translation scheme is
basically just a flattening -- you just pretend that the various levels are
there, as best I got it. I've ordered the Thinking Machine's tech
report on Paralation Lisp, as well as others.
Russ Tuck (UNC/Duke Ph.D. student) had an interesting concept of "optimal
portability" for programming languages, which he applied to SIMD
architectures. The idea is that you specify for an algorithm what
architectural class you want it to run on, and the language allows you
to use (only) the data structures and operations available in that
class. Thus you can in one basic language program as portably or
non-portably as you want, trading efficiency for portability as
appropriate to each algorithm. I've got his paper.
I met a grad student of Kale''s (Illinois), who gave me a new report
on Kale''s Chare Kernel Language (which is to C as Lamina is to Lisp,
roughly).
And that, I'm afraid, was about the size of it!
∂22-Oct-88 1826 @polya.Stanford.EDU:gangolli@wolvesden.Stanford.EDU This week's talk
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Oct 88 18:25:40 PDT
Received: from wolvesden.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA24702; Sat, 22 Oct 88 18:24:00 PDT
Received: by wolvesden.Stanford.EDU (5.51/inc-1.01)
id AA18071; Sat, 22 Oct 88 18:22:54 PDT
Message-Id: <8810230122.AA18071@wolvesden.Stanford.EDU>
To: aflb-all@wolvesden.Stanford.EDU
Subject: This week's talk
Date: Sat, 22 Oct 88 18:22:53 PDT
From: Anil R. Gangolli <gangolli@wolvesden.Stanford.EDU>
I'm sorry that the scheduling information was left out of the
abstract in the previous message. Plambeck's talk will be at
12:30pm, Thursday Oct. 28, in MJH 352 (the usual place and time).
∂22-Oct-88 1826 @polya.Stanford.EDU:gangolli@wolvesden.Stanford.EDU AFLB talk
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Oct 88 18:24:08 PDT
Received: from wolvesden.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA24646; Sat, 22 Oct 88 18:21:27 PDT
Received: by wolvesden.Stanford.EDU (5.51/inc-1.01)
id AA18064; Sat, 22 Oct 88 18:20:22 PDT
Message-Id: <8810230120.AA18064@wolvesden.Stanford.EDU>
To: aflb-all@polya.stanford.edu
Subject: AFLB talk
Date: Sat, 22 Oct 88 18:20:21 PDT
From: Anil R. Gangolli <gangolli@wolvesden.Stanford.EDU>
Periodicity Results for Some Simple
Octal Games
Thane Plambeck
Taking and breaking games are a class of impartial games played by
removing beans from a pile and leaving the pile in zero or more
parts. Following Conway, the rules for a taking and breaking game can
specified as a numeric code which describes the number of beans one
can take and the number of piles into which one can break a pile.
The games which have Conway codes consisting only of the octal digits
0...7 are known as octal games.
The theorem of Sprague and Grundy tells us that every instance of an
impartial game is equivalent to an instance of the game Nim. The
instances of a taking and breaking game thus specify a sequence of Nim
values. It is conjectured [R. Guy] that all finitely-specified octal
games have ultimately periodic Nim-value sequences, but the conjecture
is not known to hold even for all octal games with 3 or fewer code
digits. Slightly fewer than sixty of these now remain unsettled.
We present techniques for giving computational proofs of the periodicity
of some of these sequences and consequent periodicity results for three such
games.
No background in the theory of impartial games will be assumed.
This is joint work with Anil Gangolli.
∂22-Oct-88 1909 LOGMTC-mailer anyone interested?
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Oct 88 19:09:00 PDT
Received: from localhost by russell.Stanford.EDU (4.0/4.7); Sat, 22 Oct 88 19:11:20 PDT
To: logic@russell.Stanford.EDU, stass@russell.Stanford.EDU
Subject: anyone interested?
Xaddress: CSLI, Stanford University, Stanford, CA94305 (415)723-2030
Date: Sat, 22 Oct 88 19:11:18 PDT
From: Syun Tutiya <tutiya@russell.Stanford.EDU>
There will be a casual visitor from ICOT who has been working on
designing a concurrent programming language, A'UM. She seems greatly
inspired by Peter Aczel's AFA and wants to discuss her ideas with
anyone interested while she is here. She will visit CSLI on the
afternoon of Nov. 15th. If any one of you is interested, send a
message on line either to me(tutiya@csli) or directly to her, whose
address is
yoshida%icot.jp@relay.cs.net
Thanks.
Syun
∂24-Oct-88 0813 @SUMEX-AIM.Stanford.EDU:mxh@ksl.stanford.edu [weening@gang-of-four.stanford.edu (Joe Weening) : PhD Oral seminar
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Oct 88 08:13:21 PDT
Received: from ksl.stanford.edu by SUMEX-AIM.Stanford.EDU with TCP; Mon, 24 Oct 88 08:08:02 PDT
Received: by ksl.stanford.edu (4.0/inc-1.0)
id AA16566; Mon, 24 Oct 88 08:12:28 PDT
Date: Mon, 24 Oct 1988 8:12:28 PDT
From: Max Hailperin <mxh@ksl.stanford.edu>
To: aap@aim.stanford.edu
Subject: [weening@gang-of-four.stanford.edu (Joe Weening) : PhD Oral seminar
]
Message-Id: <CMM.0.88.593709148.mxh@ksl.stanford.edu>
Return-Path: <@SUMEX-AIM.Stanford.EDU:usenet@labrea.stanford.edu>
Received: from SUMEX-AIM.Stanford.EDU by ksl.stanford.edu (4.0/inc-1.0)
id AA09979; Sat, 22 Oct 88 15:59:22 PDT
Received: from labrea.stanford.edu by SUMEX-AIM.Stanford.EDU with TCP; Sat, 22 Oct 88 15:54:52 PDT
Received: by labrea.stanford.edu; Sat, 22 Oct 88 15:56:43 PDT
Date: 22 Oct 88 22:57:11 GMT
>From: weening@gang-of-four.stanford.edu (Joe Weening)
Organization: Stanford University
Subject: PhD Oral seminar
Message-Id: <4628@polya.Stanford.EDU>
Sender: usenet@labrea.stanford.edu
To: su-events@labrea.stanford.edu
PARALLEL EXECUTION OF LISP PROGRAMS
Joseph S. Weening
Computer Science Department
Friday, Oct. 28, 2:15 p.m.
Building 200 (History), Room 203
Recently there have been several proposed extensions to Lisp to
express concurrency, in order to run Lisp programs on shared-memory
multiprocessors. The best-known of these languages are Multilisp, by
Halstead at MIT; and Qlisp, by Gabriel and McCarthy at Stanford.
These systems agree on the basic machine model, and have similar
language constructs for creating and controlling parallel processes.
Expression of parallelism is explicit---it is done either by the
programmer, or by source code analysis tools that detect parallelism
in ordinary code.
The multiprocessor systems for which these languages were designed
have a small or medium number of processors (tens or perhaps hundreds,
but not thousands), and in many cases the parallelism specified in a
program is more than enough to keep all of the processors busy. In
this case, limiting the amount of parallelism becomes important both
to minimize overhead and to avoid having the system run out of memory.
Proper scheduling of the processes is also necessary for the system to
work effectively.
Previous approaches to these problems of partitioning (deciding which
processes to create) and scheduling have focused on preprocessing and
compile-time analysis. For problems in symbolic computation and
artificial intelligence, the information needed to make these
decisions is often not available until runtime. This dissertation
therefore investigates several runtime partitioning and scheduling
methods. Some of these methods base their decisions on information
about the program and the data it is processing, while others examine
the state of the multiprocessor system itself.
These methods are examined both theoretically and experimentally. For
certain classes of programs, we are able to show upper bounds on the
amount of overhead caused by each of the methods, and predict the
programs' performance. Experiments confirm these predictions. Our
experiments were performed both with a multiprocessor simulator, which
can simulate any number of processors and can vary the cost of basic
operations, and with the current implementation of Qlisp on an
8-processor Alliant FX/8.
∂24-Oct-88 0946 DAVIS@Score.Stanford.EDU room schedulig
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Oct 88 09:46:39 PDT
Date: Mon 24 Oct 88 09:38:54-PDT
From: Thea Davis <DAVIS@Score.Stanford.EDU>
Subject: room schedulig
To: CSD-list@Score.Stanford.EDU
Message-ID: <12441011796.9.DAVIS@Score.Stanford.EDU>
Everyone that has a room scheduled send me the days and the time
scheduled. The sooner the better.
-------
∂24-Oct-88 1003 @Score.Stanford.EDU:winograd@loire.stanford.edu Meeting of Undergraduate Major committee - MON 10/31, 3pm - MJH220
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Oct 88 10:02:40 PDT
Received: from loire.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 24 Oct 88 09:59:21-PDT
Received: by loire.stanford.edu (4.0/SMI-DDN)
id AA28900; Mon, 24 Oct 88 09:34:51 PDT
Date: Mon, 24 Oct 88 09:34:51 PDT
From: winograd@loire.stanford.edu (Terry Winograd)
Message-Id: <8810241634.AA28900@loire.stanford.edu>
To: Cleron@polya, Fisher@score, Gupta@score, Jones@score, Mitchell@score,
Reges@score, Reid@glacier, Stager@score, r.rhino@macbeth,
s.spirou@macbeth
Subject: Meeting of Undergraduate Major committee - MON 10/31, 3pm - MJH220
Cc: Faculty@score
The first meeting of the UNDERGRADUATE MAJOR COMMITTEE will be held
next Monday Oct. 31 from 3 to 4pm in MJH220 (Nils' conference room).
The purpose of the meeting is to orient me and other people who are new
to the committee as to where things stand and what issues we should be
thinking about. I am counting on those with knowledge (e.g., the
lecturers and student representatives) to help the rest of us get a
sense of what is going on.
In general, I want the committee to do more than just set requirements
and deal with crises. In the course of the year I want us to consider
(along with the students and other faculty) what we are really trying
to do with the major, and whether we are taking steps to do it right.
As background, consider the following comments and questions:
1) A major is not a set of requirements, but a preparation. Different
majors are oriented to prepare people for diferent kinds of work:
VOCATIONAL: Assumes that the major will be the last schooling that
students get, and that they need to be prepared to take on jobs in
the industry using the specific technical skills learned in the
major. Some engineering majors are like this.
PRE-PROFESSIONAL: Assumes that students will take professional
positions, where further education is possible and in which they
feel a sense of career development. The basic orientation is to
build a base for their work as practitioners. Medical and legal
education is like this, as is our Masters program.
ACADEMIC: Assumes that students will go for higher degrees and will
concentrate on research (and possibly teaching) in their later
careers. The preparation should concentrate on a foundation of
fundamental subjects, leaving detailed technical mastery of
computing techniques for later.
Although these are not totally incompatible, they are also not the
same. A program designed for one may not suit everyone. Should we
make a choice? Should there be distinct "tracks"?
2) A major is more than a collection of courses. It is a social
structure in which students learn what computer science is and in which
they learn how to function as professionals in the field. This comes
about through personal contact -- with faculty and staff, with graduate
students, and with other undergraduates in the major. Some of it is
structured (e.g., advising) and some informal (e.g., gathering places
where people run into each other; opportunity to attend research
meetings and seminars). We have a severe problem to start with, in the
almost total physical segregation of the undergraduate program from the
rest of the department. Are we doing enough to overcome this? In
general is our major providing a learning envrionment connected with
computer science, or is it just fulfilling the requirements of the
registrar's office? What could we do better?
This is more than we can discuss in one meeting. The agenda for the
31st is to start the discussions and see what more concrete form they
might take, leading towards specific plans and actions in subsequent
meetings.
--t
∂24-Oct-88 1133 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Meeting of Undergraduate Major committee - MON 10/31, 3pm - MJH220
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Oct 88 11:33:51 PDT
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 24 Oct 88 11:30:46-PDT
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA25678; Mon, 24 Oct 88 11:21:31 PDT
Date: Mon, 24 Oct 88 11:21:31 PDT
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8810241821.AA25678@Tenaya.stanford.edu>
To: winograd@loire.stanford.edu
Cc: Cleron@polya, Fisher@score, Gupta@score, Jones@score, Mitchell@score,
Reges@score, Reid@glacier, Stager@score, r.rhino@macbeth,
s.spirou@macbeth, Faculty@score
In-Reply-To: Terry Winograd's message of Mon, 24 Oct 88 09:34:51 PDT <8810241634.AA28900@loire.stanford.edu>
Subject: Meeting of Undergraduate Major committee - MON 10/31, 3pm - MJH220
Sometime the committee on the ug major should also discuss what can
be done to encourage more participation by the senior faculty in the
teaching of introductory CS courses (if, indeed, that is an advisable
thing to encourage). For example, should teaching an intro course
count more points toward fulfilling the teaching requirement? -Nils
∂24-Oct-88 1519 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Meeting of Undergraduate Major committee - MON 10/31, 3pm - MJH220
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Oct 88 15:19:24 PDT
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 24 Oct 88 15:16:19-PDT
Message-ID: <h7sJe@SAIL.Stanford.EDU>
Date: 24 Oct 88 1516 PDT
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: Meeting of Undergraduate Major committee - MON 10/31, 3pm - MJH220
To: nilsson@TENAYA.Stanford.EDU
CC: winograd@LOIRE.STANFORD.EDU, Cleron@POLYA.STANFORD.EDU, Fisher@SCORE.Stanford.EDU,
Gupta@SCORE.Stanford.EDU, Jones@SCORE.Stanford.EDU,
Mitchell@SCORE.Stanford.EDU, Reges@SCORE.Stanford.EDU, Reid@GLACIER.Stanford.EDU,
Stager@SCORE.Stanford.EDU, r.rhino@MACBETH.Stanford.EDU,
s.spirou@MACBETH.Stanford.EDU, Faculty@SCORE.Stanford.EDU
I'm not convinced that it is advisable to encourage the senior faculty to
teach introductory CS courses (the CS10x variety, that is). I do think it
is advisable to encourage the senior faculty to teach advanced
undergraduate and beginning graduate courses (the 100 and 200 variety)
that undergraduates are likely to take.
Perhaps we should consider having an undergraduate seminar course, like
the CS300 lectures that introduce faculty to the new PhD students but
geared to the level accessible to advanced undergraduates (i.e., our CS
undergrad majors).
Arthur
∂24-Oct-88 1556 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: Meeting of Undergraduate Major committee - MON 10/31, 3pm - MJH220
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Oct 88 15:56:24 PDT
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 24 Oct 88 15:53:16-PDT
Message-ID: <1T7snd@SAIL.Stanford.EDU>
Date: 24 Oct 88 1554 PDT
From: Robert W Floyd <RWF@SAIL.Stanford.EDU>
Subject: re: Meeting of Undergraduate Major committee - MON 10/31, 3pm - MJH220
To: ARK@SAIL.Stanford.EDU
CC: Faculty@SCORE.Stanford.EDU
[In reply to message from ARK sent 24 Oct 88 1516 PDT.]
I have read Artur Keller's message several times, but can
find no argument to attempt to refute.
∂24-Oct-88 1641 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Faculty Lunch - 10/25
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Oct 88 16:41:37 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 24 Oct 88 16:38:33-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA01796; Mon, 24 Oct 88 16:39:56 PDT
Date: Mon, 24 Oct 1988 16:39:26 PDT
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score
Subject: Faculty Lunch - 10/25
Message-Id: <CMM.0.87.593739566.chandler@polya.stanford.edu>
Just a reminder.....Don't miss tomorrow's faculty lunch featuring James
Wilson...who will tell us about how to cohabit with computers in the CSD
(bulletin boards, mailing lists, forwarding, pedit, lookup, help facilities,
etc). See you all there!!!!!
∂24-Oct-88 1747 @SUMEX-AIM.Stanford.EDU:Acuff@KSL.Stanford.EDU New file server
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Oct 88 17:47:28 PDT
Received: from KSL-Mac-62 by SUMEX-AIM.Stanford.EDU with TCP; Mon, 24 Oct 88 17:42:38 PDT
Message-Id: <2802731912-1607415@KSL-Mac-62>
Sender: acuff@KSL-Mac-62
Date: Mon, 24 Oct 88 17:38:32 PDT
Reply-To: Acuff@KSL.Stanford.EDU
From: Richard Acuff <Acuff@KSL.Stanford.EDU>
To: aap@Sumex-AIM.Stanford.EDU
Subject: New file server
I've set up KSL-EXP-26 in the machine room with a lot of space allocated
to files. It is my intent that this machine replace S2 and other machines
used for storing files used by the AAP with the goal of having a single
machine with high reliability and accessibility for shared files. People
that now have files on non-X26 machines that need to be accessed by other
people should move those files to X26. For instance, BAL, CARE, XCARE,
SIMPLE, HELIOS, and LAMINA should be moved (I understand Sayuri takes care of
these). Also, POLIGON, AIRTRAC, CAGE, the various ELINTS, etc. should be
moved by their caretakers. Please don't forget to update any files in
SYS:SITE; and please update X1:SITE; while you're at it. Finally, please
delete the copy on S2 if you move something from it.
-- Rich
∂24-Oct-88 2351 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu Re: Meeting of Undergraduate Major committee - MON 10/31, 3pm - MJH220
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Oct 88 23:51:48 PDT
Received: from Pescadero by SCORE.STANFORD.EDU with TCP; Mon 24 Oct 88 23:48:14-PDT
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA07774; Mon, 24 Oct 88 23:51:33 PDT
Date: Mon, 24 Oct 88 23:51:33 PDT
From: "David Cheriton" <cheriton@pescadero.stanford.edu>
Message-Id: <8810250651.AA07774@Pescadero>
To: nilsson@tenaya.Stanford.EDU, winograd@loire.Stanford.EDU
Subject: Re: Meeting of Undergraduate Major committee - MON 10/31, 3pm - MJH220
Cc: Cleron@polya.Stanford.EDU, Faculty@score.Stanford.EDU,
Fisher@score.Stanford.EDU, Gupta@score.Stanford.EDU,
Jones@score.Stanford.EDU, Mitchell@score.Stanford.EDU,
Reges@score.Stanford.EDU, Reid@glacier.Stanford.EDU,
Stager@score.Stanford.EDU, r.rhino@macbeth.Stanford.EDU,
s.spirou@macbeth.Stanford.EDU
In-Reply-To: <8810241821.AA25678@Tenaya.stanford.edu> from
nilsson@Tenaya (Nils Nilsson) on Mon, 24 Oct 88 11:21:31 PDT
I think the EE teaching formula warrants examination if we start fooling
with the formula we currently use. In particular, I believe that it
gives one credit based on both class size and level. In my personal
experience, it seems far less time-comsuming to teach an undergrad course
than the current rather large grad. courses that I and others teach,
especialy the second time or so.
If we are going to pressure faculty to change the current teaching patterns,
we should determine what the department wants and then try to get everyone
to contribute fairly to these goals (as opposed to just their own specialties).
However, I would hope that key courses at the graduate level would also
rank.
∂25-Oct-88 0809 @Score.Stanford.EDU:jlh@vsop.Stanford.EDU Re: Meeting of Undergraduate Major committee - MON 10/31, 3pm - MJH220
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Oct 88 08:09:26 PDT
Received: from vsop.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 25 Oct 88 08:06:31-PDT
Received: from LOCALHOST by vsop.Stanford.EDU (5.59/inc-1.0)
id AA03270; Tue, 25 Oct 88 07:46:22 PDT
Message-Id: <8810251446.AA03270@vsop.Stanford.EDU>
To: "David Cheriton" <cheriton@pescadero.stanford.edu>
Cc: nilsson@tenaya.Stanford.EDU, winograd@loire.Stanford.EDU,
Cleron@polya.Stanford.EDU, Faculty@score.Stanford.EDU,
Fisher@score.Stanford.EDU, Gupta@score.Stanford.EDU,
Jones@score.Stanford.EDU, Mitchell@score.Stanford.EDU,
Reges@score.Stanford.EDU, Reid@glacier.Stanford.EDU,
Stager@score.Stanford.EDU, r.rhino@macbeth.Stanford.EDU,
s.spirou@macbeth.Stanford.EDU, jlh@vsop.Stanford.EDU
Subject: Re: Meeting of Undergraduate Major committee - MON 10/31, 3pm - MJH220
In-Reply-To: Your message of Mon, 24 Oct 88 23:51:33 -0700.
<8810250651.AA07774@Pescadero>
Date: Tue, 25 Oct 88 07:46:18 PDT
From: jlh@vsop.Stanford.EDU
The EE formula only accounts for class size. Not level. Faculty have
been given teaching leave for massive overalls of UG classes.
John
∂25-Oct-88 0852 X3J13-mailer Proposed US Position Statement
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
The following is my proposed US position statement for ISO:
*********************************************************************
The US is currently supporting two standardization efforts in Lisp:
X3J13 is standardizing Common Lisp for ANSI, and IEEE is standardizing
Scheme. The US believes that these two efforts cover a wide range of
concerns and uses for Lisp: Scheme is small, elegant, and
mathematically well-founded, and Common Lisp is full-featured, mature,
and commercially viable. Therefore, the US sees no need at this time
to standardize another dialect of Lisp for use within the US. It
follows that the primary activity of WG16 is not of major importance
within the US.
Nevertheless, it appears that WG16 is planning to provide a useful
standard for Europe. For this reason, WG16 is currently defining a
dialect of Lisp called ``ISLISP'' suitable for the needs of the European
community. The US is happy to aid that process.
Common Lisp and Scheme are beginning to enjoy widespread use not only
in the US but internationally. The charter for WG16 that was
determined at its first meeting in February 1988 allows for
standardization of multiple dialects of Lisp. Therefore, the US wishes
for WG16 to propose to ISO a standard for ISO Common Lisp, to be
called ``ISO Common Lisp.'' As ISLISP is aimed at satisfying certain
needs for a certain community, so ISO Common Lisp would be aimed at
satisfying the Common Lisp needs for a certain community. The US
wishes to reserve the right to request that WG16 propose to ISO a
standard for ISO Scheme.
By making this request, the US does not intend to impede or negate the
work of WG16 on ISLISP, just as we presume that the work of the
committee on ISLISP is not intended to impede or negate the work of
X3J13 on Common Lisp or of IEEE on Scheme in the US.
The community of Common Lisp users and implementors is international
in nature: Common Lisp is in wide use in Europe, Japan, and Australia.
Implementations of Common Lisp are under way in the UK, Germany,
Italy, and Japan (and possibly other countries). ANSI is not an
international standards organization, and so it is appropriate for
WG16 to propose a standard for ISO Common Lisp to ISO. Furthermore, it
is common for various US funding agencies to require projects to be
undertaken in ISO languages when they are available. Just as it would
be unfair for Common Lisp to be imposed by law in contexts where it is
not wanted, so it would be unfair for ISLISP to be imposed within the
US. For this reason, it is important for ISO to adopt Common Lisp as
an ISO standard language.
Common Lisp has been under design and specification for 8 years.
Commercial versions of Common Lisp have been available for 4 years. It
has been shown that small memory Common Lisp implementations are
possible and that small applications can be delivered. The key is in
implementation technology and not in language design. There are a
number of companies whose entire revenue depends on selling software
written in Common Lisp. The Defense Advanced Research Projects Agency
allows software to be written in Common Lisp (as well as Ada).
The US feels that the most interesting task for WG16 is towards a next
generation dialect of Lisp, combining the best aspects of Common Lisp,
Scheme, the Common Lisp Object System (now officially part of Common
Lisp), and other interesting (possibly parallel) dialects of Lisp.
The US believes that this task can begin once the needs of current
Lisp programmers and implementors is satisfied with ISO ISLISP and ISO
Common Lisp.
∂25-Oct-88 0858 DELAGI@SUMEX-AIM.Stanford.EDU [wall@decwrl.dec.com (David Wall): BASS 15]
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Oct 88 08:58:11 PDT
Date: Tue, 25 Oct 88 08:48:35 PDT
From: Bruce A. Delagi <DELAGI@SUMEX-AIM.Stanford.EDU>
Subject: [wall@decwrl.dec.com (David Wall): BASS 15]
To: aap@SUMEX-AIM.Stanford.EDU, waitz@granite.dec.com, nakano@granite.dec.com,
thapar@SUMEX-AIM.Stanford.EDU
Message-ID: <12441264781.26.DELAGI@SUMEX-AIM.Stanford.EDU>
Return-Path: <wall@decwrl.dec.com>
Received: from decwrl.dec.com by SUMEX-AIM.Stanford.EDU with TCP; Mon, 24 Oct 88 15:50:16 PDT
Received: from granite.pa.dec.com by decwrl.dec.com (5.54.5/4.7.34)
id AA22575; Mon, 24 Oct 88 13:15:42 PDT
Received: from acetes.pa.dec.com by granite.DEC.COM (5.54.3/4.7.34)
id AA11538; Mon, 24 Oct 88 12:00:30 PDT
Received: by acetes.pa.dec.com (5.57/4.7.34)
id AA19040; Mon, 24 Oct 88 12:00:09 PDT
Date: Mon, 24 Oct 88 12:00:09 PDT
From: wall@decwrl.dec.com (David Wall)
Message-Id: <8810241900.AA19040@acetes.pa.dec.com>
To: escd!bass@decwrl.dec.com, stanford-square@decwrl.dec.com
Subject: BASS 15
Here is the program for BASS-15. Please let me know whether you will
be there, and whether you will be there for lunch, by Wednesday at the
latest. Thanks.
David
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
15th Bay Area Systems Seminar
Date: Friday, October 28, 1988
Location: 5M Auditorium (Bldg 5)
HP Laboratories
1501 Page Mill Road (Turn in to HP at Peter Coutts Rd.)
Palo Alto, CA
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Program:
9:15 Coffee and assorted pastries
10:00 PCR: The PARC/Portable Common Runtime
Mark Weiser, Xerox PARC
11:00 ELINT in LAMINA: Application of a Concurrent Object Language
Bruce Delagi, DEC & Stanford University
12:00 Buffet Lunch (provided)
1:30 The Multi-User Interface Project
Philip Gust, HP Labs
2:30 A Framework for Textual Search on Office Systems
David M. Choy, IBM Almaden Research Center
3:30 Adjourn
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
ABSTRACTS
PCR: The PARC/Portable Common Runtime
Mark Weiser
Xerox PARC
PCR defines a set of useful capabilities that many languages can share.
These include: dynamic loading, load-state management, garbage collection,
and threads. For each capability, PCR provides a base implementation, and
a set of call back procedures for use by languages that can't leave well
enough alone. For instance, the garbage collector will use conservative
collection on C code, but liberal collection for Lisp code because Lisp
will have callbacks that inform the collector where to find the Lisp
pointers. For some implementations the PCR will simply pass through
capabilities of the underlying O.S. (e.g. threads on Mach).
The PCR is intended to be portable to many different operating systems, and
be useful to many different languages. We currently have run it on only a
few flavors of one operating system (Unix), and a few flavors of languages
(Cedar, C, Lisp).
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
ELINT in LAMINA: Application of a Concurrent Object Language
Bruce Delagi
Digital Equipment Corporation/Stanford University
The design and performance of an "expert system" signal interpretation
application written in a concurrent object-based programming language,
LAMINA, is described together with a synopsis of the programming model
that forms the basis of the language. The effects of load balancing
and the limits imposed by task granularity and message transmission costs
are studied and their consequences to application performance are measured
over the range of one to 256 processors as simulated in SIMPLE/CARE, an
extensively instrumented simulation system and computer array model.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The Multi-User Interface Project
Philip Gust
Hewlett-Packard Laboratories
People who work together in groups have very different computing needs
than people who work alone. While individuals use computers to create
and analyze information, groups also rely on them to communicate with
each other, to coordinate their activities, and to share information.
Moving beyond today's distributed computing to create a true
cooperative computing environment will require us to reexamine many of
the assumptions underlying the design of today's computer platforms.
In a cooperative computing environment, for example the user interface
mediates interactions not only between users and computers, but also
among users. A multi-user interface is based on a model that includes
people, how they interact with each other, and how they jointly
manipulate information across time and place. The model must address
three key requirements in a multi-user environment: how people
communicate with each other, how they coordinate their activities, and
how share information.
The Multi-User Interface Project at HP Labs is currently exploring
some of these issues by building on the X user interface architecture
to create an experimental group computing environment. One of our
projects is Shared X, an extension to the X window system that allows
existing applications to be used as "groupware", while providing
additional capabilities for new kinds of collaborative applications.
We are also experimenting with new spatial metaphors that are better
suited for groups than the simple "desktop". Our preliminary effort
is to create a new user interface component in the X architecture that
is responsible for presenting and managing spatial metaphors, and to
validate our design by implementing multi-user versions of the
"desktop" and "rooms" metaphors.
Finally, we are working with several other research groups to add
video capability to X for future experiments in integrating tools for
group communication.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
A Framework for Textual Search on Office Systems
David M. Choy
IBM Almaden Research Center
As increasingly more office information is stored on-line, a content
search capability on text data is highly desirable. While indexing
and search techniques developed over the years for Information
Retrieval (IR) systems are usable, the design of IR systems is
typically based on:
- A specific application,
- A particular model of user interface, and/or
- A special indexing/search technique.
Adopting such a design will inevitably restrict the ability of the
system to support a wide variety of applications, to subsequently
introduce a new indexing/search algorithm, and to support a new user
interface. Indeed, most office applications have different
requirements from the traditional IR applications.
In this talk, a syntactic model of text data and text matching is
examined. This more generic approach allows us to propose an
architecture for a text search engine which has little dependency on
the application and the indexing method.
Furthermore, assuming an inverted-index implementation of this method,
a collection of search algorithms is developed. An analysis of the
worst-case complexity of these algorithms suggests that this approach
to text-search is quite feasible.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-------
∂25-Oct-88 0944 @Score.Stanford.EDU:jwilson@jaguar.Stanford.EDU Meeting of CSD Database committee
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Oct 88 09:43:56 PDT
Received: from jaguar.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 25 Oct 88 09:38:47-PDT
Received: by jaguar.Stanford.EDU (5.51/inc-1.01)
id AA10037; Tue, 25 Oct 88 09:44:11 PDT
Date: Tue, 25 Oct 88 09:44:11 PDT
From: James Wilson <jwilson@jaguar.Stanford.EDU>
Message-Id: <8810251644.AA10037@jaguar.Stanford.EDU>
To: csddb@jaguar.Stanford.EDU
Cc: faculty@score.stanford.edu, davis@score.stanford.edu
Subject: Meeting of CSD Database committee
The CSD Database Committee will meet this Thursday (October 27) from
10:30am until 11:30am to discuss which database we should recommend
for the Department to use. At this meeting, I hope we can make a
final decision on which database to use.
James
∂25-Oct-88 0950 @Score.Stanford.EDU:jwilson@jaguar.Stanford.EDU Where the meeting of CSD Database committee will be held
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Oct 88 09:50:11 PDT
Received: from jaguar.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 25 Oct 88 09:44:36-PDT
Received: by jaguar.Stanford.EDU (5.51/inc-1.01)
id AA10076; Tue, 25 Oct 88 09:50:02 PDT
Date: Tue, 25 Oct 88 09:50:02 PDT
From: James Wilson <jwilson@jaguar.Stanford.EDU>
Message-Id: <8810251650.AA10076@jaguar.Stanford.EDU>
To: csddb@jaguar.Stanford.EDU
Cc: faculty@score.stanford.edu, davis@score.stanford.edu
Subject: Where the meeting of CSD Database committee will be held
Forgot to add -- it will be in MJH 252.
James
∂25-Oct-88 1013 @Score.Stanford.EDU:dill@amadeus.STANFORD.EDU undergrad major
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Oct 88 10:12:56 PDT
Received: from amadeus.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Tue 25 Oct 88 10:10:06-PDT
Received: by amadeus.STANFORD.EDU (5.59/inc-1.0)
id AA26425; Tue, 25 Oct 88 10:11:31 PDT
Date: Tue, 25 Oct 88 10:11:31 PDT
From: dill@amadeus.STANFORD.EDU (David Dill)
Message-Id: <8810251711.AA26425@amadeus.STANFORD.EDU>
To: faculty@score.stanford.edu
Subject: undergrad major
A few more issues that I wonder about:
1. Are we getting the students we want? My course has a lot of
students from other majors and graduate departments. Most of the
bottom 10% are undergrad CS Majors (Of course, we get some brilliant
students, too). Are they majoring in CS because of a love for the
area, or because they think the degree will pay off?
2. Content of the first few courses. As an example, students in my
compiler course said he was bored because 108B had covered LL(1)
parsing when he took it (FIRST, FOLLOW sets and everything). In my
opinion, 108B has no business teaching that material. Furthermore, I
could not assume it as a prerequisite even if I wanted to -- the
great majority of the class has not seen this material (they are MSCS
from other schools, students from other departments, or perhaps 108B
varies). The content of interacting courses should be negotiated
between them.
3. Compatibility with the MSCS program (related to 2). Our program
must integrate large numbers of people from other schools at least
somewhat smoothly.
4. Stability in the undergraduate program.
∂25-Oct-88 1030 STAGER@Score.Stanford.EDU Preliminary Class Lists
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Oct 88 10:29:57 PDT
Date: Tue 25 Oct 88 10:25:51-PDT
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: Preliminary Class Lists
To: faculty@Score.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12441282487.11.STAGER@Score.Stanford.EDU>
I'll be sending out the Autumn Quarter preliminary class lists shortly. Our
courier will deliver them to mail boxes later today. Please let me know
if you don't receive yours within the next few days.
PLEASE NOTE:
CS393 (Computer Laboratory) is listed as a 1-6 unit course. However, many
students have been signing up for more than 6 units (up to 18 in some cases).
Please note the units listed for your CS393 students, and consider whether we
want to enforce the current limit, or perhaps raise it.
Thanks.
Claire
-------
∂25-Oct-88 1038 barwise@russell.Stanford.EDU ra support for new program
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Oct 88 10:38:18 PDT
Received: from localhost by russell.Stanford.EDU (4.0/4.7); Tue, 25 Oct 88 10:39:27 PDT
To: ssp-faculty@russell.Stanford.EDU
Subject: ra support for new program
Date: Tue, 25 Oct 88 10:39:25 PDT
From: Jon Barwise <barwise@russell.Stanford.EDU>
At the lunch on Friday, Nils mentioned that students in the
new program who worked with faculty with support for RA's
might be picked up that way. In talking to the deans about
support for the program, it would be useful for me to be
able to hold this out as a way in which the program would
not inevitably need 4 years of support per student. Would
those of you who could imagine supporting a student working
with you under this program for a year or two let me know?
Thanks.
Jon
∂25-Oct-88 1217 @Score.Stanford.EDU:WIEDERHOLD@SUMEX-AIM.Stanford.EDU Re: Preliminary Class Lists
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Oct 88 12:17:41 PDT
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 25 Oct 88 12:14:32-PDT
Date: Tue, 25 Oct 88 12:00:20 PDT
From: Gio Wiederhold <WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
Subject: Re: Preliminary Class Lists
To: STAGER@score.Stanford.EDU
cc: faculty@score.Stanford.EDU
In-Reply-To: <12441282487.11.STAGER@Score.Stanford.EDU>
Message-ID: <12441299686.68.WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
Let's raise it. Also CS395.
No need in principle for any limit. But giving 18 units means something funny
is going on. I use the rule that 4 hours of work equals one unit. An 18 unit
course implies that the student is putting in 72 hours/week.
That makes him/her eligible for overtime. Gio
-------
∂25-Oct-88 1403 DELAGI@SUMEX-AIM.Stanford.EDU [kaplan%kaplan.cs.uiuc.edu@a.cs.uiuc.edu (Simon Kaplan): Concurrent Object-Based Programming List]
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Oct 88 14:03:04 PDT
Date: Tue, 25 Oct 88 13:56:14 PDT
From: Bruce A. Delagi <DELAGI@SUMEX-AIM.Stanford.EDU>
Subject: [kaplan%kaplan.cs.uiuc.edu@a.cs.uiuc.edu (Simon Kaplan): Concurrent Object-Based Programming List]
To: aap@SUMEX-AIM.Stanford.EDU
Message-ID: <12441320786.65.DELAGI@SUMEX-AIM.Stanford.EDU>
Return-Path: <kaplan%kaplan.cs.uiuc.edu@a.cs.uiuc.edu>
Received: from a.cs.uiuc.edu by SUMEX-AIM.Stanford.EDU with TCP; Tue, 25 Oct 88 13:31:09 PDT
Received: from kaplan (kaplan.cs.uiuc.edu) by a.cs.uiuc.edu with SMTP (UIUC-5.52/9.7)
id AA00988; Tue, 25 Oct 88 15:34:07 CDT
Received: by kaplan (4.0/9.7)
id AA00953; Tue, 25 Oct 88 15:34:06 CDT
Date: Tue, 25 Oct 88 15:34:06 CDT
From: kaplan%kaplan.cs.uiuc.edu@a.cs.uiuc.edu (Simon Kaplan)
Message-Id: <8810252034.AA00953@kaplan>
To: delagi@sumex-aim.stanford.edu
Subject: Concurrent Object-Based Programming List
(This is a retransmission for people whose mail addresses did not work.
Hopefully my attempts at surgery will repair the problem
Simon)
Hi everyone,
At the workshop on concurrent object-based programming, we agreed to
establish a newsgroup which would act as a forum for the ongoing discussion
of topics of interest to the group. This is the first message that will go
out to the group. I'm sending it for 3 reasons:
1. to let you know that the group exists.
2. to weed out bad addresses
3. to explain how to use the list
4. to forward to you a message from Gul Agha (see below).
I am initially planning not to "moderate" the list in the sense of
controlling messages; rather, I will act as a forwarding point, ie send
mail to one of the given addresses below and it will get forwarded to the
rest of the list. If the noise level gets too high then I will change to a
moderated format, but that is a lot of work and I would rather not do it.
anyway: the list is called "obcp", for object-based concurrent
programming. To send a message to the list, use one of these addresses:
obcp@a.cs.uiuc.edu or kaplan@cs.uiuc.edu (internet)
obcp.cs.uiuc.edu@relay.cs.net (csnet)
uunet!uiucdcs!obcp (usenet)
obcp@uiucvmd.bitnet (bitnet)
For adminstration (to add or remove members of the list), use "obcp-request"
instead of "obcp" as the user-id in the above addresses.
For personal stuff (like you cant get thru on obcp, or you want to suggest
things more privately, or whatever) substitute "kaplan" for "obcp".
If several persons at a site are interested in the mailgroup, you can set
up a local "mini-distribution" list and just give me the name of that
mini-list. that greatly reduces the amount of effort needed by me to
maintain the list. A very effective way of doing this is to use the
"notesfile" electronic bulletin board system developed here; send me email
for more info about this.
These addresses will be operational after 17:00 Central time today.
(some of you may see this message a couple of times, due ironing out the
bugs in the mail lists)
And now, here is the message from Gul. I look forward to reading the
traffic on the net.
-----------------------------
Date: Tue, 25 Oct 88 13:31:40 EDT
From: gul agha <agha-gul@YALE.ARPA>
Dear Colleagues,
Thank you for your participation in the workshop on Object-Based
Concurrent Programming earlier this fall. I am sure you would agree
that the workshop proved to be very successful. Following discussions
at the workshop, we have also starting a mail group over the net of
people interested in the area. Simon Kaplan at University of Illionis
has graciously offered to moderate this newsgroup. Please send him
any postings or addition requests.
I would like to take this opportunity to remind you that your research
summaries for the special issue of SIGPLAN Notices are due by Oct. 31.
Please send four camera-ready copies on 8 1/2in by 11in or A4 unlined
paper, with the text covering no more than 7in by 10in (18cm by 25cm)
centered on the page. Authors' professional affiliations and the full
mailing address of at least one author should appear on the first
page. Please send the papers to the address below:
Ted Leung
Dept. of Computer Science
TJ Watson Center for Information Technology
115 Waterman St.
Brown University
Providence, RI 02906
(401)863-7685
If you are going to be late by a few days, please let us know by
sending a message to Ted at twl@CS.BROWN.EDU.
We look forward to hearing from you!
Sincerely,
Gul Agha
-------
∂25-Oct-88 1405 X3J13-mailer Comments on Cleanup issues due within two weeks
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 25 Oct 88 14:05:19 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 25 OCT 88 13:50:39 PDT
Date: 25 Oct 88 13:50 PDT
From: masinter.pa@Xerox.COM
Subject: Comments on Cleanup issues due within two weeks
To: X3J13@Sail.stanford.edu
reply-to: CL-Cleanup@sail.stanford.edu
Message-ID: <881025-135039-11718@Xerox>
As was discussed in the October X3J13 meeting, there will be a letter
ballot on the outstanding previously distributed cleanup issues. In order
for us to respond to your comments, we need to receive any comments on any
of the issues that were mailed electronically and distributed in hardcopy
within the next two weeks. If you feel that the cleanup proposals as
written adequately consider all of the possible alternatives, properly
address the costs and benefits of the proposal, we don't need to hear from
you. However, if there are considerations you believe are not reflected in
the writeup, please speak up. So far, we have heard from very few people.
I expect at the January meeting that there will be discussion of those
issues that we were unable to prepare for the October meeting, and there
will be some opportunity to discuss the items and the results of the letter
ballot, but I hope you will take the time, now, to consider the issues
already distributed.
You will do those of us who try to track cleanup mail a favor if you will
use a separate message for each Issue, with Subject: Issue: ISSUE-NAME
(Version number), addressed To: CL-Cleanup@sail.stanford.edu. Will will try
to ensure that all contributors are cc'd in subsequent discussion.
Thanks,
Larry Masinter
∂26-Oct-88 0619 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu code wanted for exact tsp and reduce
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Oct 88 06:19:39 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA13833; Wed, 26 Oct 88 06:19:26 PDT
Message-Id: <8810261319.AA13833@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 26 Oct 88 06:20:00 PDT
Received: by BYUADMIN (Mailer R2.01) id 3627; Wed, 26 Oct 88 07:18:12 MDT
Date: Mon, 24 Oct 88 16:53:46 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Marty Cohen <mcohen@NRTC.NORTHROP.COM>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Marty Cohen <mcohen@NRTC.NORTHROP.COM>
Subject: code wanted for exact tsp and reduce
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Is code (C, Fortran, Common Lisp, or Pascal) available for:
1. An exact solution to the traveling salesman problem, naturally
for a small (under 30) number of points (on the Euclidean
plane is ok).
2. The symbolic math package REDUCE.
Please send pointers or (for #1) actual code to
mcohen@nrtc.northrop.com (128.99.0.1)
If there is any interest, I will summarize the responses.
Thanks
Marty Cohen
∂26-Oct-88 0624 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu funny-bug
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Oct 88 06:24:35 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA13861; Wed, 26 Oct 88 06:24:30 PDT
Message-Id: <8810261324.AA13861@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 26 Oct 88 06:25:04 PDT
Received: by BYUADMIN (Mailer R2.01) id 4151; Wed, 26 Oct 88 07:23:31 MDT
Date: Mon, 24 Oct 88 17:15:03 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
David Harel <HAREL%WISDOM.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: David Harel <HAREL%WISDOM.BITNET@forsythe.stanford.edu>
Subject: funny-bug
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
I am trying to find the reference to a delightful computer bug reported
by someone from Denmark or The Netherlands in a letter to the editor of
CACM or IEEE Computer, I think, somewhere in the past 2 years or so.
It concerns a lady who, around her 107th birthday, received a computer-
generated letter from the Ministry of Education instructing her in how
to register for first grade. The bug, of course, was in the 2-digit
allowance for the "age" field in the database...
Where did this appear?
David Harel (harel@wisdom.bitnet)
∂26-Oct-88 1036 @Score.Stanford.EDU:jwilson@jaguar.Stanford.EDU Availability of Mac Plus and IBM XT machines
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Oct 88 10:36:02 PDT
Received: from jaguar.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 26 Oct 88 10:32:53-PDT
Received: by jaguar.Stanford.EDU (5.51/inc-1.01)
id AA10992; Wed, 26 Oct 88 10:38:50 PDT
Date: Wed, 26 Oct 88 10:38:50 PDT
From: James Wilson <jwilson@jaguar.Stanford.EDU>
Message-Id: <8810261738.AA10992@jaguar.Stanford.EDU>
To: faculty@score.stanford.edu
Subject: Availability of Mac Plus and IBM XT machines
We have the possibility of getting several Mac Plus and IBM XT machines
at no cost. These machines may be used for faculty use, student use,
or even department staff usage.
If you want any of these machines, you must let me know by this Friday
(Oct 28). Please tell me how many you want and how the machine(s) will
be used (please try to be specific).
A synopsis of the letter sent by Bob Eustis:
-----------------------------------------------------------------------
Bob Eustis sent out a message regarding Computer Recycling. Apple has
promised the School of Engineering 330 Mac II computers over the next
two years. He asked that anyone receiving a Mac II who earlier
received a Mac Plus (or IBM XT), return the Plus (or IBM XT) to the
School of Engineering for use by faculty, student computing clusters,
or departmental staff.
To distribute these computers, departments are being asked to make short
proposals for their use.
∂26-Oct-88 1424 @Score.Stanford.EDU:katiyar@polya.Stanford.EDU CSD Autumn Potluck!
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Oct 88 14:23:54 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 26 Oct 88 14:15:03-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA07050; Wed, 26 Oct 88 14:17:06 PDT
Date: Wed, 26 Oct 1988 14:17:04 PDT
From: "Dinesh H. Katiyar" <katiyar@polya.stanford.edu>
To: students@score, faculty@score, research-associates@score,
secretaries@score
Subject: CSD Autumn Potluck!
Message-Id: <CMM.0.87.593903824.katiyar@polya.stanford.edu>
********** 1988 AUTUMN QUARTER POTLUCK **********
The Student Social Committee is proud to announce:
The CSD Autumn Potluck!!!
Who : All CSD faculty, students, and staff
What : The CSD Potluck, of course.
Where: Terry Winograd's house
When : Saturday November 12, 6:00pm
Why : Why not? (It'll be fun!)
How : See map below:
In order to guarantee that you have a place to sit or stand, and
something besides 100 bags of potato chips to eat, we have made up a
sign-up sheet.
Run the program ~katiyar/food on polya. This program will allow you
to edit (using "vi", with apologies to all you emacs users out there)
the potluck sign-up sheet. Please add your name and e-mail address to
the list under the category of food you plan to bring.
Those of you who don't have accounts on polya can send mail to one
of the members of the social committee.
Please respond as soon as possible. We only have room for 100-120 people.
---------------------------------------------------------------------
Terry and Carol Winograd
746 Esplanada Way, Stanford
494-1716
=+===+=================Junipero Serra======+==============+===+==+=...
| . |
| . |
| | Mayfield |
| ...----+------------------------+--------...
S| | C| Tressider
t| | @@@@@@@ a|
a| Esplanada Way @ 746 @ m|
n| 0---------+-----------0 @@@@@@@ p|
f| | u| Law
o| \ Alvarado s| School
r| ------------------------+--...
d| P| D|
| i|H r|
A| n|i i|
v| e|l v| . QUAD
e| Bowdoin |l e| .
|----------------------+--------------+ |G .
| | |a .
| ...--------------+ |l |P
| Escondido Rd. \ |v |a
| + |e |l
| Escondido / \ |z |m
| Village / -----+------+--...
| Serra| | |
| | | |
=+===+============El Camino================+========+======+==...
NOT TO SCALE!
-------------------------------------------------------------------------
Student Social Committee
------------------------
jennifer anderson jaikumar ramanathan dinesh katiyar
anderson@polya jaikumar@polya katiyar@polya
-------------------------------------------------------------------------
∂26-Oct-88 1649 @Score.Stanford.EDU:jwilson@jaguar.Stanford.EDU CSD Autumn Potluck program may use vi or emacs
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Oct 88 16:49:05 PDT
Received: from jaguar.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 26 Oct 88 14:47:51-PDT
Received: by jaguar.Stanford.EDU (5.51/inc-1.01)
id AA11299; Wed, 26 Oct 88 14:54:18 PDT
Date: Wed, 26 Oct 88 14:54:18 PDT
From: James Wilson <jwilson@jaguar.Stanford.EDU>
Message-Id: <8810262154.AA11299@jaguar.Stanford.EDU>
To: katiyar@polya.stanford.edu
Cc: students@score.stanford.edu, faculty@score.stanford.edu,
research-associates@score.stanford.edu, secretaries@score.stanford.edu
In-Reply-To: "Dinesh H. Katiyar"'s message of Wed, 26 Oct 1988 14:17:04 PDT <CMM.0.87.593903824.katiyar@polya.stanford.edu>
Subject: CSD Autumn Potluck program may use vi or emacs
~katiyar/food has been modified to ask if you want to use vi or emacs.
∂26-Oct-88 1840 emma@csli.Stanford.EDU CSLI Calendar, October 27, 4:6
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Oct 88 18:40:35 PDT
Received: by csli.Stanford.EDU (4.0/4.7); Wed, 26 Oct 88 17:10:49 PDT
Date: Wed, 26 Oct 88 17:10:49 PDT
From: emma@csli.Stanford.EDU (Emma Pease)
To: friends@csli.Stanford.EDU
Subject: CSLI Calendar, October 27, 4:6
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
27 October 1988 Stanford Vol. 4, No. 6
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 27 October 1988
12 noon TINLecture
Cordura Hall Chaos
Conference Room Bernardo Huberman
(huberman.pa@xerox.com)
Abstract in last week's Calendar
2:15 p.m. CSLI Seminar
Cordura Hall Week 5: Early AI Research on Local Pragmatics
Conference Room Jerry Hobbs
(hobbs@warbucks.ai.sri.com)
Abstract in last week's Calendar
3:45 p.m. Tea
Ventura Hall
____________
CSLI ACTIVITIES FOR NEXT THURSDAY, 3 November 1988
12 noon TINLab
Cordura Hall What is Planning? What does it have to do with
Conference Room Language Processing?
Ray Perrault
(rperrault@ai.sri.com)
Abstract below
2:15 p.m. CSLI Seminar
Cordura Hall Week 6: Knowledge-based Approaches to the
Conference Room Resolution Problem
Jerry Hobbs
(hobbs@warbucks.ai.sri.com)
Abstract below
3:45 p.m. Tea
Ventura Hall
____________
NEXT WEEK'S TINLAB
What is Planning? What does it have to do with Language Processing?
Ray Perrault
(rperrault@ai.sri.com)
November 3
Various notions of `plan', or complex action, have been developed in
AI in the course of developing programs that can automatically
construct courses of behavior to achieve certain goals. Tradeoffs can
be made between the expressive power of the languages in which states
and actions can be expressed and the computational difficulty of
processes by which plans can be constructed, i.e., `planning', or
inferred, i.e., `plan recognition'.
We will review some of the main lines of research on plans in AI,
as well as applications made of those notions to problems in language
understanding, including language generation, speech act theory, and
understanding of stories and dialogues.
____________
NEXT WEEK'S CSLI SEMINAR
The Resolution Problem for Natural-Language Processing
Weeks 6: Knowledge-based Approaches to the Resolution Problem
Jerry Hobbs
(hobbs@warbucks.ai.sri.com)
November 3
We will continue examining various AI approaches to the resolution
problem, concentrating on those that try to make extensive use of
world knowledge and context. We will especially be looking at the
work of Hirst, Charniak, and approaches using abductive inference.
--------------
CSLI TALK
Proof Normalization with Nonstandard Objects
Shigeki Goto
Nippon Telegraph and Telephone Corporation
Monday, 31 October, 2:30
Cordura Conference Room 100
It is well known that formal proof systems can serve as programming
languages. A proof that describes an algorithm can be executed by
Prawitz's normalization procedure. This talk extends the
computational use of proofs to realize a lazy computation formally.
It enables computation of a proof over stream objects (infinitely long
lists) as in Concurrent Prolog.
To deal with infinitely long objects, we will extend the number
theory to incorporate infinite numbers. This is an application of
nonstandard analysis to computer programs. We will show that the rule
of mathematical induction can be extended to cover infinite numbers
with appropriate computational meaning.
The method of introducing nonstandard integers was independently
proposed by the speaker (Goto) and Professor Per Martin-Lof at
Stockholm University. He will briefly discuss Martin-Lof's extension
of his constructive type theory.
--------------
TALK
Minds, Machines, and Searle
Stevan Harnad
(harnad@princeton.edu)
Thursday, 3 November, 10:00
Cordura Hall Conference Room
Searle's provocative "Chinese Room Argument" attempted to show that
the goals of "Strong AI" are unrealizable. Proponents of Strong AI
are supposed to believe that (i) the mind is a computer program, (ii)
the brain is irrelevant, and (iii) the Turing Test is decisive.
Searle's point is that since the programmed symbol-manipulating
instructions of a computer capable of passing the Turing Test for
understanding Chinese could always be performed instead by a person
who could not understand Chinese, the computer can hardly be said to
understand Chinese. Such "simulated" understanding, Searle argues, is
not the same as real understanding, which can only be accomplished by
something that "duplicates" the "causal powers" of the brain. In this
paper I make the following points:
1. Simulation versus Implementation
2. Theory-Testing versus Turing-Testing
3. The Convergence Argument
4. Brain Modeling versus Mind Modeling
5. The Modularity Assumption
6. The Teletype versus the Robot Turing Test
7. The Transducer/Effector Argument
8. Robotics and Causality
9. Symbolic Functionalism versus Robotic Functionalism
10. "Strong" versus "Weak" AI
---------------
NEW PUBLICATIONS
The CSLI Publications Office is pleased to announce the publication of
three new titles.
---------------------------------------------
The second edition of Johan van Benthem's
"A Manual of Intensional Logic"
(Revised and Expanded)
Intensional logic, as understood here, is based on the broad
presupposition that so-called intensional contexts in natural language
can be explained semantically by the idea of multiple reference. Van
Benthem reviews work on tense, modality, and conditionals and then
presents recent developments in intensional theory, including
partiality and generalized quantifiers. The text of the first edition
has been substantially revised, and three new chapters have been
added.
Johan van Benthem is professor of mathematical logic at the University
of Amsterdam.
Cloth: $29.95 ISBN: 0-937073-30-X
Paper: $12.95 ISBN: 0-937073-29-6
---------------------------------------------
Tore Langholm's
"Partiality, Truth and Persistence"
This book is a study in the theory of partially defined models.
Langholm compares in detail the various alternatives for extending the
definition of truth or falsity that holds with classical, complete
models to partial models. He also investigates the monotonicity of
truth and other inexpressible conditions. These discussions culminate
with a combined Lindstrom and persistence characterization theorem.
Tore Langholm is a research fellow in mathematics at the University of
Oslo.
Cloth: $29.95 ISBN: 0-937073-35-0
Paper: $12.95 ISBN: 0-937073-34-2
---------------------------------------------
"Papers from the Second International
Conference on Japanese Syntax"
(Edited by William Poser)
Cloth: $40.00 ISBN: 0-937073-39-3
Paper: $15.95 ISBN: 0-937073-38-5
---------------------------------------------
These titles are distributed by the Univesity of Chicago Press and may
be purchased in academic or university bookstores or ordered directly
from the distributor at 5801 Ellis Avenue, Chicago, Illinois 60637.
(1-800) 621-2736.
∂26-Oct-88 1925 X3J13-mailer Proposed US Position Statement
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Oct 88 19:25:15 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 482712; Wed 26-Oct-88 22:25:20 EDT
Date: Wed, 26 Oct 88 22:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposed US Position Statement
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: x3j13@SAIL.Stanford.EDU
In-Reply-To: <$7Wc0@SAIL.Stanford.EDU>
Message-ID: <19881027022508.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is fine with me, except for the part at the end suggesting that
the best place to do Lisp language research is in an ISO standards
committee. That seems like the worst place to me.
∂27-Oct-88 1040 TAJNAI@Score.Stanford.EDU interested in spending sabbatical at IBM Tokyo Research Labs?
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Oct 88 10:40:39 PDT
Date: Thu 27 Oct 88 10:38:36-PDT
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: interested in spending sabbatical at IBM Tokyo Research Labs?
To: faculty@Score.Stanford.EDU
cc: hiller@Score.Stanford.EDU
Message-ID: <12441809097.19.TAJNAI@Score.Stanford.EDU>
Dr. Nori Suzuki, Director of the IBM Toyko Research Laboratories, is
interested in having a professor spend 6 months at the labs in Tokyo.
Housing, salary provided. Let me know if you are interested.
Carolyn
-------
∂27-Oct-88 1441 DEWERK@Score.Stanford.EDU CS-TAC
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Oct 88 14:40:55 PDT
Date: Thu 27 Oct 88 14:32:14-PDT
From: Gerda de Werk <DEWERK@Score.Stanford.EDU>
Subject: CS-TAC
To: csd-list@Score.Stanford.EDU
Message-ID: <12441851627.11.DEWERK@Score.Stanford.EDU>
CS-TAC will be shutdown from 7:00am-5:00pm, 10/27-10/31. A
construction crew is currently erecting a steel structure on the deck
of the CSD/LOTS area, and as a safety precaution, noone is allowed in
the building while the crew is working; however, the building will be
open from 5:00pm until 2:00am everyday.
If you need to get ahold of a CS-TAC person prior to next Tuesday
morning, e-mail will probably work best.
Gerda de Werk
-------
∂27-Oct-88 1521 @Score.Stanford.EDU:dash@polya.Stanford.EDU Re: CS-TAC
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Oct 88 15:21:16 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 27 Oct 88 14:59:45-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA12421; Thu, 27 Oct 88 14:59:59 PDT
Date: Thu, 27 Oct 88 14:59:59 PDT
From: David Ash <dash@polya.Stanford.EDU>
Message-Id: <8810272159.AA12421@polya.Stanford.EDU>
To: DEWERK@Score.Stanford.EDU, csd-list@Score.Stanford.EDU
Subject: Re: CS-TAC
Gerda:
You may not be the person to speak to about this, and if so I apologize for
bothering you. However, it would have been nice to know about the shutdown of
TAC in advance of its happening. I showed up to TA this morning to find the
building shut tighter than a drum, and had no way of telling the students in
the course about the cancellation.
As I said, this probably has nothing to do with you directly. In that case, I'd
appreciate your sending me the name of the person to whom I should address my
concern. Thanks a lot for your help, and for sending me the message which did
clear up my question about when TAC was reopening.
-David
∂27-Oct-88 1603 @Score.Stanford.EDU:warren@Portia.stanford.edu Re: CS-TAC
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Oct 88 16:03:44 PDT
Received: from Portia.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 27 Oct 88 15:52:03-PDT
Received: by Portia.stanford.edu (5.54/inc-1.2)
id AA28077; Thu, 27 Oct 88 15:51:06 PDT
Date: Thu, 27 Oct 88 15:51:06 PDT
From: warren@Portia.stanford.edu (Mark Warren)
Message-Id: <8810272251.AA28077@Portia.stanford.edu>
To: DEWERK@Score.Stanford.EDU, csd-list@Score.Stanford.EDU,
dash@polya.Stanford.EDU
Subject: Re: CS-TAC
From @Score.Stanford.EDU:dash@polya.Stanford.EDU Thu Oct 27 15:21:49 1988
Return-Path: <@Score.Stanford.EDU:dash@polya.Stanford.EDU>
Received: from Score.Stanford.EDU by Portia.stanford.edu (5.54/inc-1.2)
id AA25488; Thu, 27 Oct 88 15:21:06 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 27 Oct 88 14:59:45-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA12421; Thu, 27 Oct 88 14:59:59 PDT
Date: Thu, 27 Oct 88 14:59:59 PDT
From: David Ash <dash@polya.Stanford.EDU>
Message-Id: <8810272159.AA12421@polya.Stanford.EDU>
To: DEWERK@Score.Stanford.EDU, csd-list@Score.Stanford.EDU
Subject: Re: CS-TAC
Gerda:
You may not be the person to speak to about this, and if so I apologize for
bothering you. However, it would have been nice to know about the shutdown of
TAC in advance of its happening. I showed up to TA this morning to find the
building shut tighter than a drum, and had no way of telling the students in
the course about the cancellation.
As I said, this probably has nothing to do with you directly. In that case, I'd
appreciate your sending me the name of the person to whom I should address my
concern. Thanks a lot for your help, and for sending me the message which did
clear up my question about when TAC was reopening.
-David
Perhaps you sent this using a mailing list?
I'm not Gerda, I hape she got a copy of this.
-- Mark Warren
∂27-Oct-88 1623 DELAGI@SUMEX-AIM.Stanford.EDU [kaplan%kaplan.cs.uiuc.edu@a.cs.uiuc.edu (Simon Kaplan): Concurrent Object-Based Programming List]
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Oct 88 16:23:01 PDT
Date: Thu, 27 Oct 88 16:15:32 PDT
From: Bruce A. Delagi <DELAGI@SUMEX-AIM.Stanford.EDU>
Subject: [kaplan%kaplan.cs.uiuc.edu@a.cs.uiuc.edu (Simon Kaplan): Concurrent Object-Based Programming List]
To: aap@SUMEX-AIM.Stanford.EDU
Message-ID: <12441870432.42.DELAGI@SUMEX-AIM.Stanford.EDU>
Return-Path: <kaplan%kaplan.cs.uiuc.edu@a.cs.uiuc.edu>
Received: from a.cs.uiuc.edu by SUMEX-AIM.Stanford.EDU with TCP; Tue, 25 Oct 88 13:31:09 PDT
Received: from kaplan (kaplan.cs.uiuc.edu) by a.cs.uiuc.edu with SMTP (UIUC-5.52/9.7)
id AA00988; Tue, 25 Oct 88 15:34:07 CDT
Received: by kaplan (4.0/9.7)
id AA00953; Tue, 25 Oct 88 15:34:06 CDT
Date: Tue, 25 Oct 88 15:34:06 CDT
From: kaplan%kaplan.cs.uiuc.edu@a.cs.uiuc.edu (Simon Kaplan)
Message-Id: <8810252034.AA00953@kaplan>
To: delagi@sumex-aim.stanford.edu
Subject: Concurrent Object-Based Programming List
(This is a retransmission for people whose mail addresses did not work.
Hopefully my attempts at surgery will repair the problem
Simon)
Hi everyone,
At the workshop on concurrent object-based programming, we agreed to
establish a newsgroup which would act as a forum for the ongoing discussion
of topics of interest to the group. This is the first message that will go
out to the group. I'm sending it for 3 reasons:
1. to let you know that the group exists.
2. to weed out bad addresses
3. to explain how to use the list
4. to forward to you a message from Gul Agha (see below).
I am initially planning not to "moderate" the list in the sense of
controlling messages; rather, I will act as a forwarding point, ie send
mail to one of the given addresses below and it will get forwarded to the
rest of the list. If the noise level gets too high then I will change to a
moderated format, but that is a lot of work and I would rather not do it.
anyway: the list is called "obcp", for object-based concurrent
programming. To send a message to the list, use one of these addresses:
obcp@a.cs.uiuc.edu or kaplan@cs.uiuc.edu (internet)
obcp.cs.uiuc.edu@relay.cs.net (csnet)
uunet!uiucdcs!obcp (usenet)
obcp@uiucvmd.bitnet (bitnet)
For adminstration (to add or remove members of the list), use "obcp-request"
instead of "obcp" as the user-id in the above addresses.
For personal stuff (like you cant get thru on obcp, or you want to suggest
things more privately, or whatever) substitute "kaplan" for "obcp".
If several persons at a site are interested in the mailgroup, you can set
up a local "mini-distribution" list and just give me the name of that
mini-list. that greatly reduces the amount of effort needed by me to
maintain the list. A very effective way of doing this is to use the
"notesfile" electronic bulletin board system developed here; send me email
for more info about this.
These addresses will be operational after 17:00 Central time today.
(some of you may see this message a couple of times, due ironing out the
bugs in the mail lists)
And now, here is the message from Gul. I look forward to reading the
traffic on the net.
-----------------------------
Date: Tue, 25 Oct 88 13:31:40 EDT
From: gul agha <agha-gul@YALE.ARPA>
Dear Colleagues,
Thank you for your participation in the workshop on Object-Based
Concurrent Programming earlier this fall. I am sure you would agree
that the workshop proved to be very successful. Following discussions
at the workshop, we have also starting a mail group over the net of
people interested in the area. Simon Kaplan at University of Illionis
has graciously offered to moderate this newsgroup. Please send him
any postings or addition requests.
I would like to take this opportunity to remind you that your research
summaries for the special issue of SIGPLAN Notices are due by Oct. 31.
Please send four camera-ready copies on 8 1/2in by 11in or A4 unlined
paper, with the text covering no more than 7in by 10in (18cm by 25cm)
centered on the page. Authors' professional affiliations and the full
mailing address of at least one author should appear on the first
page. Please send the papers to the address below:
Ted Leung
Dept. of Computer Science
TJ Watson Center for Information Technology
115 Waterman St.
Brown University
Providence, RI 02906
(401)863-7685
If you are going to be late by a few days, please let us know by
sending a message to Ted at twl@CS.BROWN.EDU.
We look forward to hearing from you!
Sincerely,
Gul Agha
-------
∂27-Oct-88 1645 hoffman@csli.Stanford.EDU SSP Forum Oct. 28
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Oct 88 16:45:47 PDT
Received: by csli.Stanford.EDU (4.0/4.7); Thu, 27 Oct 88 16:40:42 PDT
Date: Thu 27 Oct 88 16:40:40-PDT
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: SSP Forum Oct. 28
To: forum-faculty@csli.Stanford.EDU, ssp-forum@csli.Stanford.EDU
Message-Id: <593998841.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
This week's Symbolic Systems Forum is actually the Kant Lecture, a complete
list of which was announced earlier. Next week's Forum will also be a
Kant lecture and the week after we will see Barwise and Etchemendy talking on
Logic and Information.
-------
∂27-Oct-88 1737 @Score.Stanford.EDU:dwhitney@Portia.stanford.edu Re: CS-TAC
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Oct 88 17:37:18 PDT
Received: from Portia.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 27 Oct 88 16:43:25-PDT
Received: by Portia.stanford.edu (5.54/inc-1.2)
id AA03183; Thu, 27 Oct 88 16:42:37 PDT
Date: Thu, 27 Oct 88 16:42:37 PDT
From: dwhitney@Portia.stanford.edu (David Whitney)
Message-Id: <8810272342.AA03183@Portia.stanford.edu>
To: DEWERK@Score.Stanford.EDU, csd-list@Score.Stanford.EDU,
dash@polya.Stanford.EDU, warren@Portia.stanford.edu
Subject: Re: CS-TAC
Yes, she did, as did the rest of the world.
∂27-Oct-88 1801 @Score.Stanford.EDU:koch@polya.Stanford.EDU Re: CS-TAC
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Oct 88 18:01:41 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 27 Oct 88 17:55:47-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA26879; Thu, 27 Oct 88 17:56:05 PDT
Date: Thu, 27 Oct 88 17:56:05 PDT
From: Dorothee Koch <koch@polya.Stanford.EDU>
Message-Id: <8810280056.AA26879@polya.Stanford.EDU>
To: DEWERK@Score.Stanford.EDU, csd-list@Score.Stanford.EDU,
dash@polya.Stanford.EDU
Subject: Re: CS-TAC
How about that: if everybody used a *capital* R to reply to messages in Unix;
that sends the answer only to the original sender, instead of sending
it out to everybody on the list by replying with *small* r.
Dorothee
∂27-Oct-88 2254 @Score.Stanford.EDU:seidel@Portia.stanford.edu Re: CS-TAC
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Oct 88 22:53:59 PDT
Received: from Portia.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 27 Oct 88 22:47:52-PDT
Received: by Portia.stanford.edu (5.54/inc-1.2)
id AA03415; Thu, 27 Oct 88 22:47:01 PDT
Message-Id: <8810280547.AA03415@Portia.stanford.edu>
Date: 27 Oct 1988 2246-PDT (Thursday)
From: Craig Seidel <seidel@Portia.stanford.edu>
To: seidel
Subject: Re: CS-TAC
In-Reply-To: Dorothee Koch <koch@polya.Stanford.EDU> /
Thu, 27 Oct 88 17:56:05 PDT.
<8810280056.AA26879@polya.Stanford.EDU>
Folks,
A useful convention is to use the bcc: (blind carbon copy) feature
of mail when sending to a large group (i.e. send it to yourself, but
send a blind carbon copy to everyone else). When people reply to a
message, it does NOT go to the addresses on the bcc:.
Recent prediction: If current trends continue, by the year 2010
computer scientists will spend all their time reading e-mail. :-)
Thanks,
Craig
∂27-Oct-88 2329 @polya.Stanford.EDU:tah@linz MTC Seminar Today
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Oct 88 23:29:43 PDT
Received: from linz.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA09816; Thu, 27 Oct 88 23:29:06 PDT
Received: by linz.stanford.edu (4.0/SMI-DDN)
id AA26983; Thu, 27 Oct 88 23:25:43 PDT
Message-Id: <8810280625.AA26983@linz.stanford.edu>
To: lop@polya
Subject: MTC Seminar Today
Date: 27 Oct 88 23:25:23 PDT (Thu)
From: Tom Henzinger <tah@linz>
12 noon, MJH 322.
I think we've decided to continue today with Scott's paper (Roger
will present the correspondence between typed lambda calculi and
ccc's), and then switch to something else next week.
∂27-Oct-88 2339 @polya.Stanford.EDU:tah@linz MTC Seminar, 2nd Down
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Oct 88 23:39:51 PDT
Received: from linz.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA10090; Thu, 27 Oct 88 23:39:19 PDT
Received: by linz.stanford.edu (4.0/SMI-DDN)
id AA27001; Thu, 27 Oct 88 23:35:57 PDT
Message-Id: <8810280635.AA27001@linz.stanford.edu>
To: lop@polya
Subject: MTC Seminar, 2nd Down
Date: 27 Oct 88 23:35:36 PDT (Thu)
From: Tom Henzinger <tah@linz>
It's in MJH 301 (322 would be kind of crowded).
P.S.: I pledge to never send email past 10 p.m. ever again ...
-- Tom.
∂28-Oct-88 0000 @Score.Stanford.EDU:gandalf@csli.Stanford.EDU Please!
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Oct 88 23:59:57 PDT
Received: from csli.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 27 Oct 88 23:54:00-PDT
Received: by csli.Stanford.EDU (4.0/4.7); Thu, 27 Oct 88 23:55:55 PDT
Date: Thu, 27 Oct 88 23:55:55 PDT
From: gandalf@csli.Stanford.EDU (Juergen Wagner)
To: csd-list@score
Subject: Please!
Can we please move the discussion about various techniques of
e-mailing to su.computers?
--Juergen
∂28-Oct-88 0347 X3J13-mailer mailing list update
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 28 Oct 88 03:47:26 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA22930; Fri, 28 Oct 88 03:47:05 PDT
Message-Id: <8810281047.AA22930@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 28 Oct 88 06:44
To: x3j13@sail.stanford.edu
Subject: mailing list update
Please remove Ron Ohlander from x3j13.
∂28-Oct-88 1136 @Score.Stanford.EDU:tom@polya.Stanford.EDU [GX.LOO@Forsythe.Stanford.EDU: Mathematica Presentation 11/2/88]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Oct 88 11:36:34 PDT
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 28 Oct 88 11:33:22-PDT
Received: by polya.Stanford.EDU (5.59/25-eef) id AA27578; Fri, 28 Oct 88 11:33:39 PDT
Date: Fri, 28 Oct 88 11:33:39 PDT
From: Tom Dienstbier <tom@polya.Stanford.EDU>
Message-Id: <8810281833.AA27578@polya.Stanford.EDU>
To: faculty@score, csd@score
Subject: [GX.LOO@Forsythe.Stanford.EDU: Mathematica Presentation 11/2/88]
FYI
Return-Path: <@Score.Stanford.EDU:GX.LOO@Forsythe.Stanford.EDU>
Date: Fri, 28 Oct 88 10:56:51 PDT
To: TOM@SCORE
From: "Maile Loo" <GX.LOO@Forsythe.Stanford.EDU>
Subject: Mathematica Presentation 11/2/88
Stephan Wolfram, a founder of Wolfram Research, Inc., will discuss and
demonstrate Mathematica at 7:30pm Wed, November 2 in Terman Auditorium.
Mathematica is a software system capable of performing calculations in
all areas of mathematics. The program is designed to make algebra,
calculus, geometry and other areas of mathematics as straightforward
as the calculator has made simple arithmetic. Mathematica operates
not only with numbers and algebraic formulae, but also with graphics.
Users can produce two-and three-dimensional pictures that allow them
to visualize complex mathematical functions.
In addition to having an extensive collection of built-in functions,
Mathematica is also a powerful programming language in which
applications can be written. According to Wolfram, Mathematica is
"... a tool for anyone who uses mathematics, whether they are math
professors, engineers, or high school students."
Mathematica can be used with many kinds of computers, including
personal computers, workstations, and supercomputers. Versions of
Mathematica are available for a variety of computers including Apple
Macintosh, Ardent, IBM, NeXT, Silicon Graphics, Sony, Stellar and Sun.
-------
∂28-Oct-88 1607 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu THE MATHEMATICAL REVOLUTION INSPIRED BY COMPUTING
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Oct 88 16:07:03 PDT
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA16538; Fri, 28 Oct 88 16:06:13 PDT
Message-Id: <8810282306.AA16538@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 28 Oct 88 16:06:44 PDT
Received: by BYUADMIN (Mailer R2.01) id 8148; Fri, 28 Oct 88 17:04:34 MDT
Date: Fri, 28 Oct 88 08:46:40 CDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Chic Rattray <cr%CS.STIR.AC.UK@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Chic Rattray <cr%CS.STIR.AC.UK@Forsythe.Stanford.EDU>
Subject: THE MATHEMATICAL REVOLUTION INSPIRED BY COMPUTING
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
The Institute of Mathematics and Its Application
THE MATHEMATICAL REVOLUTION INSPIRED BY COMPUTING
Brighton Polytechnic, 5th - 7th April 1989
Call for Papers
The Institute of Mathematics and Its Application is holding a
conference with the theme "The Mathematical Revolution Inspired
By Computing" which will be held at Brighton Polytechnic between
Wednesday 5th April and Friday 7th April, 1989.
The conference is intended to reflect how computing is changing
mathematics, and how new mathematics needs to be developed for
computing and its applications. The Committee is seeking papers
in the following areas (but not exclusively so):
Logics and Theorem Proving; Graphs, Networks and Automata;
Complexity and Measurement; Algebra and Category Theory;
Mathematics for describing Complex Systems; Computational
Tools; Data Representation and Pattern Matching; any major
new area of mathematics arising from computing such as frac-
tals, image processing and cryptography.
Rather than addressing the above topics from the viewpoint of
computer science papers, authors should attempt to show how
mathematics has been influenced by computing, how new areas of
mathematics have opened up, or how computing has generated new
concepts and problems in mathematics.
Invited speakers include: Professor B. de Neumann, FIMA (City
University), Professor Dan Simpson, FIMA (Brighton Polytechnic),
Dr T. Maibaum (Imperial College), Professor F. Piper, FIMA (Royal
Holloway & Bedford New College), Professor S. Seidman (George Ma-
son University, Virginia), and Professor J. Serra (Fontainbleau,
France).
Contributed papers are invited and will be accepted on the basis
of a 300 - 500 word abstract which should be submitted by 15th
November, 1988. Authors will be informed of acceptance by 31st
December, 1988.
On the first evening there will be a debate with the motion
"There is no Mathematical Revolution due to Computing", and a
conference dinner will be held on the following evening.
Members of the Organising Committee are: Dr J.H. Johnson, FIMA
(Open University), Mr T. Denvir (Praxis Systems PLC), Dr N. Fen-
ton, AFIMA (South Bank Polytechnic), Dr B. Monohan (Cambridge
University), Dr D. Pitt (University of Surrey), Mr C.M.I. Rat-
tray, FIMA (University of Stirling), and Dr R. Whitty, AFIMA
(Goldsmith's College, London).
Abstracts and all other enquiries should be sent to: Miss Shirley
Wardle, Conference Officer, The IMA, Maitland House, Southend-
on-Sea, Essex SS1 2JY, UK.
-----------------------------------------------------------------
To: Miss Shirley Wardle, Conference Officer, The Institute of
Mathematics and Its Applications, Maitland House, Warrior Square,
Southend-on-Sea, Essex SS1 1JY.
IMA CONFERENCE ON THE MATHEMATICAL REVOLUTION INSPIRED BY COMPUTING
Final date for abstracts: 15th November, 1988.
Notice to authors: 31st December, 1988.
TITLE...... FIRST NAME.......... SURNAME................
INSTITUTION...............................................
.........................................................
ADDRESS FOR CORRESPONDENCE................................
.........................................................
Date ....... Signature ...............
Grade (If IMA Member) .........
I intend to submit an abstract ......
Please send me an application form when available ......
∂28-Oct-88 1629 REGES@Score.Stanford.EDU addendum to Tom's msg RE Wolfram/Mathematica
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Oct 88 16:27:48 PDT
Date: Fri 28 Oct 88 16:25:27-PDT
From: Stuart Reges <REGES@Score.Stanford.EDU>
Subject: addendum to Tom's msg RE Wolfram/Mathematica
To: faculty@Score.Stanford.EDU
In-Reply-To: <8810281833.AA27578@polya.Stanford.EDU>
Office: CS-TAC 22, 723-9798
Message-ID: <12442134382.9.REGES@Score.Stanford.EDU>
Wolfram is a really fascinating guy and I highly recommend attending his talk
and looking at his product. It is an amazingly powerful mathematical and
symbolic engine. You might be interested to know that Mathematica is going to
be bundled for free with every NeXT machine. That's nice for people who like
to play directly in Mathematica and for software writers who want to call it as
a package. I believe it costs something like $500 to obtain a copy of the
product for the Mac. I understand that Wolfram offered Apple a deal where they
could bundle it with every Mac II at a cost of $50 each to Apple, but they
didn't go for it. Wolfram's people are working on putting a lot of the logic
of the program into a custom chip so that he can announce a cheap and fast
Mathematica workstation in conjunction with some hardward vendor that he wasn't
at liberty to name (I believe it's probably Commodore for their Amiga).
-------
∂31-Oct-88 0830 @Score.Stanford.EDU:chandler@polya.Stanford.EDU This weeks faculty lunch....
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 31 Oct 88 08:30:50 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 31 Oct 88 08:28:59-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA14322; Mon, 31 Oct 88 08:29:35 PDT
Date: Mon, 31 Oct 1988 8:29:33 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score
Cc: na.adp@forsythe
Subject: This weeks faculty lunch....
Message-Id: <CMM.0.87.594318573.chandler@polya.stanford.edu>
tomorrow, November 1, in room MJH-146 at 12:15. Andy diPaulo, Director of
Stanford Instructional Television Network will be our guest to talk about new
directions for SITN. See you there!!!!!
∂31-Oct-88 1519 GENESERETH@Score.Stanford.EDU PhD Program proposal
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 31 Oct 88 15:19:34 PST
Date: Mon 31 Oct 88 15:14:13-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: PhD Program proposal
To: faculty@Score.Stanford.EDU
Message-ID: <12442918768.33.GENESERETH@Score.Stanford.EDU>
Folks,
Over the next few weeks, you should be hearing from me about a number
of proposed changes in the PhD program. This note concerns the Grey
Tuesday-Black Friday mode of student evaluation that we have used for
so long. I am proposing (1) to eliminate Grey Tuesday (but retain
Black Friday) and (2) to add in the place of Grey Tuesday quarterly
meetings of a subset of the PhD committee (including both faculty and
students). There are several reasons for this proposal.
We now have far more PhD students than we did when the old scheme was
initiated. When I first came to Stanford, standard practice in Grey
Tuesday was to review the progress of EVERY PhD student. Gene Golub
used to say that this was the only chance we got to hear the names of
our students. However, due to our increased size, we are no longer
able to do this. At best we can review the students who are in
trouble.
Another problem is that our current review scheme is at odds with
university guidelines, at least for cases of dismissal. For example,
the guidelines for dismissal of a stuident after candidacy require
three separate meetings : (1) a meeting of student with Advisor,
head of PhD Committee, and other interested faculty at which lack of
progress is determined (our old Grey Tuesday) (2) a meeting at which
the decision for dismissal is made (Black Friday), and (3) a
meeting at which the student has the right to appeal that decision.
There is also provision for an additional review (at the department's
option) if the decision at meeting (3) is negative.
This last year we fixed things up in part by adding a post-Black
Friday meeting to handle those students who were faced with dismissal.
However, we still are doing it right yet. Hence the proposal
to drop Grey Tuesday and initiate these quarterly meetings in its
stead.
First of all, I like the quarterly meetings because, occurring
quarterly, we would get four chances each year to monitor student
progress instead of just two. We could act more quickly, should
we decide that dismissal is appropriate.
Secondly, being small meetings we could afford to spend more time on
each student than in full faculty meetings like Grey Tuesday and Black
Friday. We could also afford to pay attention to people who may be
getting into trouble but arent there yet. And we could acknowledge
cases of exceptionally good progress.
Of course, we COULD retain Grey Tuesday AND have these small meetings
as well but that is definitely redundant. If we are to devote
time to these smaller meetings, then we should economize elsewhere.
I propose to save on Grey Tuesday.
Of course, we COULD also drop Black Friday. However, I'd like to keep
it for two reasons. First of all, if we are going to dismiss someone,
I would like the full faculty to hear thecase and make the decision.
We could work the meetings so that the second meeting required by the
university (the dismissal decision) is the Black Friday meeting. The
second reason for keeping Black Friday is that I'd like to use it for
advertising the progress of other students as well, not just the ones
in trouble, so that, as Gene has always wanted, we get to hear these
names, and we get to hear about good progress as well as problems. In
the past this was not possible because Black Friday WAS the review
meeting. Under the new scheme, most of the work would be done in the
small committee meeting. We would be sure to have all of the relevant
information beforehand. Come to think of it, maybe we should stop
calling it Black Friday. How about "White Friday" or "Black and White
Friday" or "Checkered Friday".
Well, at this pont I would like to get some feeback. If there
are no overwhelming argumenst against the proposal we will put it
effect this year. Comments?
mrg
-------
∂31-Oct-88 1652 misha@polya.Stanford.EDU Next AFLB - UNUSUAL TIME AND PLACE!
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 31 Oct 88 16:52:01 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA25108; Mon, 31 Oct 88 16:46:58 PDT
Date: Mon, 31 Oct 88 16:46:58 PDT
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8811010046.AA25108@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: Next AFLB - UNUSUAL TIME AND PLACE!
Please note unusual time and place!
The next AFLB will meet next FRIDAY, NOV 4 (instead of Thursday, Nov 3)
at 2:30 pm in room 301.
Take a Walk and Grow a Tree on the Boolean Hypercube.
Jin-Yi Cai
Yale University
We present a simple randomized algorithm for maintaining
dynamically evolving binary trees on hypercube networks.
The algorithm guarantees that: (1) nodes adjacent in the tree are
within distance $O(\log\log N)$ in an $N$ processor hypercube, and
(2) with overwhelming probability, no hypercube processor is assigned more
than $O(1+\frac{M}{N})$ tree nodes, where $M$ is the number of nodes
in the tree. The algorithm is distributed and does not require any
global information. This is the first load-balancing algorithm with
provably good performance.
The algorithm can be used to efficiently parallelize any tree based
computation such as divide-and-conquer, branch-and-bound, or
functional expression evaluation. It can also be used to
efficiently maintain dynamic data structures such as quad-trees that
arise in scientific applications and image processing.
A novel technique -- tree surgery -- is introduced to deal with
dependencies inherent in trees. Together with tree surgery, the study
of random walks is used to analyze the algorithm.
(Joint work with Sandeep Bhatt.)
------------------------------------------------------------------------
-------
∂01-Nov-88 0011 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: PhD Program proposal
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Nov 88 00:11:26 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 1 Nov 88 00:08:34-PST
Message-ID: <dq08S@SAIL.Stanford.EDU>
Date: 01 Nov 88 0009 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: PhD Program proposal
To: GENESERETH@Score.Stanford.EDU
CC: faculty@Score.Stanford.EDU
I wholeheartedly endorse the spirit of Mike's suggestion. I have some
questions, however, about who would be at the quarterly review meetings,
and how the advisors were to represent the students who were in trouble.
One advantage of the current Grey Tuesday scheme is that, if all the
faculty are there, student status and defense can be provided by the
advisor.
There is a potential problem of the dual Black Friday role of dismissal
proceedings and reporting the status of all the PhD students. Perhaps the
dismissal cases would come up first, and then a brief rapid-fire report on
everybody would be useful. But consider that if every PhD student were to
be talked about for one minute, it would take over 2 hours! If only
students in the third year and beyond were discussed, it would still take
well over an hour.
Below are some slightly baked thoughts on how the Quarterly and Annual
Review meetings could be run. (Quarterly and Annual Review certainly
lacks the color of Grey Tuesday and Black Friday, but they convey more
semantics. I'd go for drab but informative names over cute but
meaningless names, especially for meetings of such importance.) The
following is meant to apply to students post candidacy. I'm not sure what
to do about students who have not passed the comp yet.
Each quarter, after a meeting between the student and his/her advisor
and/or reading committee, the advisor is to write a progress report letter
to the PhD committee, and for the student file. The committee at the
Quarterly Review meetings reviews these progress reports. If progress is
behind schedule, a draft letter is sent to the advisor and reading
committee, and then after incorporating comments, is sent to the student
and placed on file. Face to face meetings between the student, the
advisor, and a representative of the PhD committee may be appropriate in
certain cases, in conjunction with the letter.
Students are identified at the Quarterly Review meeting for dismissal
proceedings at the Annual Review meeting. The advisor (and reading
committee) should be present to discuss the case. A vote is taken on the
student's status.
After the Annual Review meeting discusses dismissal cases, all other PhD
students, in reverse order by entry date, are briefly discussed, with
relevant comments by the advisor, extracts from the progress report, and
anecdotes from other faculty members, as appropriate.
Students failing to make adequate progress are to get letters from every
Quarterly Review meeting. All students receive letters of their status at
least once a year, or when their status changes. For example, students
who pass the qual are sent a letter congratulating them and reminding them
that they are expected to have a thesis topic within a year.
These comments include ideas that may help to implement Mike's suggestion.
They are not intended as formal proposals, but rather to clarify the
issues that need to be considered in this discussion.
Arthur
∂01-Nov-88 0016 @Score.Stanford.EDU:jlh@vsop.Stanford.EDU Re: PhD Program proposal
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Nov 88 00:16:16 PST
Received: from vsop.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 1 Nov 88 00:08:36-PST
Received: from LOCALHOST by vsop.Stanford.EDU (5.59/inc-1.0)
id AA10100; Mon, 31 Oct 88 23:10:22 PDT
Message-Id: <8811010710.AA10100@vsop.Stanford.EDU>
To: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Cc: faculty@Score.Stanford.EDU
Subject: Re: PhD Program proposal
In-Reply-To: Your message of Mon, 31 Oct 88 15:14:13 -0800.
<12442918768.33.GENESERETH@Score.Stanford.EDU>
Date: Mon, 31 Oct 88 23:10:05 PST
From: jlh@vsop.Stanford.EDU
I think it's a good idea. I agree the meetings have gooten too large
with too many people to review.
John
∂01-Nov-88 1139 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu a desperate call for candidates
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Nov 88 11:39:11 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA03902; Tue, 1 Nov 88 11:38:26 PDT
Message-Id: <8811011938.AA03902@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 1 Nov 88 11:38:20 PST
Received: by BYUADMIN (Mailer R2.01) id 9810; Tue, 01 Nov 88 12:37:37 MST
Date: Tue, 1 Nov 88 13:24:00 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Zvi Galil <galil%CS.COLUMBIA.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Zvi Galil <galil%CS.COLUMBIA.EDU@Forsythe.Stanford.EDU>
Subject: a desperate call for candidates
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
In my (serious!) presentation at the last
FOCS business meeting/ follies
I asked for a volunteer to run against David Johnson.
As usual, nobody took me seriously.
So I repeat. We really need someone to run against David.
Pls contact me if you are willing or if you have a serious
idea.. Our bylaws require at least two candidates for each office.
∂01-Nov-88 1237 X3J13-mailer March meeting
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Nov 88 12:35:25 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00995g; Tue, 1 Nov 88 12:34:40 PST
Received: by challenger id AA01605g; Tue, 1 Nov 88 12:30:50 PST
Date: Tue, 1 Nov 88 12:30:50 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8811012030.AA01605@challenger>
To: x3j13@sail.stanford.edu
Subject: March meeting
Bob Mathis will be hosting the March X3J13 and ISO meetings in the new Contel
facilities. Thank you Bob!
Please mark your calendars.
3/27 - 3/29 X3J13, Washington, D.C. area
3/30 - 3/31 ISO, Washington, D.C. area
---jan---
∂01-Nov-88 1245 X3J13-mailer March meeting
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 1 Nov 88 12:45:25 PST
Return-Path: <hadden@src.honeywell.com>
Received: from ella.SRC.Honeywell.COM
by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88)
id AA21106; Tue, 1 Nov 88 14:45:20 CST
Posted-Date: Tue, 1 Nov 88 14:43:47 CST
Received: by ella.src.honeywell.com (3.2/SMI-3.2)
id AA22306; Tue, 1 Nov 88 14:43:47 CST
Date: Tue, 1 Nov 88 14:43:47 CST
From: hadden@src.honeywell.com (George D. Hadden)
Message-Id: <8811012043.AA22306@ella.src.honeywell.com>
To: jlz@lucid.com
Cc: x3j13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Tue, 1 Nov 88 12:30:50 PST <8811012030.AA01605@challenger>
Subject: March meeting
oops, never mind about the dates.
-geo
∂01-Nov-88 1927 @Score.Stanford.EDU:gio@ksl.stanford.edu Re: PhD Program proposal
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Nov 88 19:27:14 PST
Received: from ksl.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 1 Nov 88 19:20:06-PST
Received: by ksl.stanford.edu (4.0/inc-1.0)
id AA29955; Tue, 1 Nov 88 19:21:30 PST
Date: Tue, 1 Nov 1988 19:21:29 PST
From: Gio Wiederhold <gio@ksl.stanford.edu>
To: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Cc: faculty@Score.Stanford.EDU
Subject: Re: PhD Program proposal
In-Reply-To: Your message of Mon 31 Oct 88 15:14:13-PST
Message-Id: <CMM.0.88.594444089.gio@ksl.stanford.edu>
maybe with the four meetings we could hear each (PhD) students name once
a year?
gio
∂02-Nov-88 0930 X3J13-mailer Hawaii hotel reservations reminder
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 2 Nov 88 09:30:11 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00503g; Wed, 2 Nov 88 09:29:23 PST
Received: by challenger id AA03055g; Wed, 2 Nov 88 09:25:32 PST
Date: Wed, 2 Nov 88 09:25:32 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8811021725.AA03055@challenger>
To: x3j13@sail.stanford.edu
Subject: Hawaii hotel reservations reminder
Please ask for Lizann when calling the Sheraton Coconut Grove 8:00 - 5:00
Monday - Friday. She is the one who can give you the special rate of
$80/night.
808/822-3455
---jan---
∂02-Nov-88 1108 @Score.Stanford.EDU:root@polya.Stanford.EDU polya account
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Nov 88 11:08:01 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 2 Nov 88 11:06:45-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA07667; Wed, 2 Nov 88 11:07:34 PDT
Date: Wed, 2 Nov 88 11:07:34 PDT
From: Mr. Big <root@polya.Stanford.EDU>
Message-Id: <8811021907.AA07667@polya.Stanford.EDU>
To: ac@polya.Stanford.EDU
Subject: polya account
the account ftp was created with password 2780d
∂02-Nov-88 1553 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu NSF support for algorithms and parallel computing systems
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Nov 88 15:53:16 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA25170; Wed, 2 Nov 88 15:53:08 PDT
Message-Id: <8811022353.AA25170@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 2 Nov 88 15:53:01 PST
Received: by BYUADMIN (Mailer R2.01) id 1659; Wed, 02 Nov 88 16:49:21 MST
Date: Wed, 2 Nov 88 14:24:35 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Errol Lloyd <elloyd@NOTE.NSF.GOV>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Errol Lloyd <elloyd@NOTE.NSF.GOV>
Subject: NSF support for algorithms and parallel computing systems
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
PRELIMINARY ANNOUNCEMENT
Beginning in FY89, NSF and DARPA will jointly support research projects
in the area of algorithm design, analysis and instrumentation for parallel
computing systems. The purpose of the program is to promote closer ties
between theory and practice. By enabling the highest quality efforts to
operate at an increased scale, the program aims to encourage collaborative
efforts that link theoretical computer science with experimentation and
engineering. Specific focal points are:
Parallel algorithms and computational models,
Analysis and instrumentation techniques for complex parallel models,
Parallel algorithm design paradigms, and
Design paradigms for parallel artificial intelligence algorithms.
The research proposed under this joint program should investigate
innovative approaches and techniques that may lead to revolutionary advances
in the state of the art. Specifically excluded are approaches that are
primarily incremental improvements to the existing state of practice.
Specific areas of interest include, but are not limited to, the following:
Parallel algorithms and data structures,
Probabilistic and randomized algorithms,
Parallel models of computation including cellular automata,
Computational geometry,
Algorithm design paradigms,
Mechanizable algorithm analysis techniques,
Instrumentation techniques,
Very high level languages for expressing parallel algorithms,
Quantitative analysis methods for heuristics, and
Design paradigms for algorithms in vision, speech, planning and learning.
Excluded from this program is work of a primarily foundational nature in
structural complexity, combinatorial mathematics and algorithm analysis, as
well as primarily application-specific algorithm design and implementation.
Approximately $1.5 Million will be awarded in FY89. Proposals for efforts
of any size will be considered. In general, support will be provided for
principal investigators, graduate students, postdoctoral research support, and
specialized equipement necessary for the conduct of the research, as well as
other funds normally allowed in an award. Proposals under this program will
be subject to the normal NSF peer review process. Special emphasis in the
review process will be given to the value gained from team research and the
capability of the plan for achieving transition of results into the research
and/or industrial communities. NSF and DARPA staffs will make final selections
from meritorious proposals. Proposals should be submitted to NSF as if they
were regular NSF submissions (for consideration by: NSF-DARPA Parallel
Computing Initiative, CCR-CISE). For technical information, prospective PIs
may contact either NSF or DARPA program offices:
DARPA - Dr. William L. Scherlis, Program Manager, Defense Advanced
Research Projects Agency, (202) 694-5800, scherlis@vax.darpa.mil
NSF - Dr. Errol L. Lloyd, Division of Computer and Computation Research,
(202) 357-7375, elloyd@note.nsf.gov
Target date for submitting proposals is December 19, 1988.
∂02-Nov-88 1604 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu PODC Call for Papers:
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Nov 88 16:04:08 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA25736; Wed, 2 Nov 88 16:03:47 PDT
Message-Id: <8811030003.AA25736@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 2 Nov 88 16:03:40 PST
Received: by BYUADMIN (Mailer R2.01) id 2187; Wed, 02 Nov 88 17:02:10 MST
Date: Wed, 2 Nov 88 14:29:15 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Michael Merritt <mischu@ALLEGRA.ATT.COM>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Michael Merritt <mischu@ALLEGRA.ATT.COM>
Subject: PODC Call for Papers:
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
______________________________________________________________________
CALL FOR PAPERS
Eighth ACM SIGACT-SIGOPS Symposium on
Principles of Distributed Computing
*************
* (PODC'89) *
*************
August 14-16, 1989
Edmonton, Alberta, Canada
Original research contributions are sought that address fundamental
issues in the theory and practice of distributed and concurrent
systems. Topics of interest include, but are not limited to:
- Principles of distributed computation derived from
practical experience with working systems
- Algorithms and complexity
- Specification, semantics, and verification
- Programming languages and programming language constructs
- Fault tolerance
- Cryptography and security
Important dates:
Jan. 30, 1989 Abstracts due
Apr. 1, 1989 Acceptance notification
May 15, 1989 Camera-ready version due
Please send 4 copies of a detailed abstract (not the complete paper),
with the address, e-mail address, and telephone number, to the Program
Chair:
Michael Merritt
AT&T Bell Laboratories
Room 3D-458
600 Mountain Avenue
Murray Hill, NJ 07974
U.S.A.
e-mail: allegra!mischu
The abstract must provide sufficient details to allow the program
committee to assess the merits of the paper and should include
appropriate references to and comparisons with literature. It is
recommended that each submission begin with a succinct statement of
the problem, a summary of the main results, and a brief explanation of
the significance and relevance to the conference, all suitable for a
non-specialist. Technical development of the work, directed to the
specialist, should follow. A limit of 10 typed double-spaced pages is
placed on submissions. If the authors believe that more details are
essential to substantiate the main claims of the paper, they are
encouraged to include a clearly marked appendix that will be read at
the discretion of the Program Committee.
Abstracts conforming to the guidelines will be considered by the
committee if they are postmarked by the deadline of January 30th,
1989, and are received within a reasonable time thereafter.
The Program Committee:
Yehuda Afek, AT&T and Tel Aviv University
Baruch Awerbuch, MIT
Edmund Clarke, Carnegie Mellon
Cynthia Dwork, IBM
Michael Fischer, Yale University
Mohamed Gouda, Univ. of Texas at Austin
Maurice Herlihy, Carnegie Mellon
Michael Merritt, AT&T
David Peleg, Weizmann Institute, Israel
Charles Rackoff, University of Toronto
Peter Weinberger, AT&T
Pierre Wolper, University of Liege, Belgium
Conference Chair:
Piotr Rudnicki, The University of Alberta, Edmonton, Canada,
(piotr@alberta.UUCP)
Publicity Chair:
M. Tamer Ozsu, The University of Alberta, Edmonton, Canada,
(ozsu@alberta.UUCP)
______________________________________________________________________
Note: the printed call for papers has an error in one reference to the date:
January 30 is the REAL deadline. M. Merritt
∂02-Nov-88 1612 X3J13-mailer Re: Proposed US Position Statement
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Nov 88 16:12:11 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 NOV 88 16:05:27 PST
Date: Wed, 2 Nov 88 16:05 PST
From: Gregor.pa@Xerox.COM
Subject: Re: Proposed US Position Statement
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: x3j13@SAIL.Stanford.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <$7Wc0@SAIL.Stanford.EDU>
Message-ID: <19881103000503.4.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
We would like to comment on your proposed US position statement for ISO
WG16. We agree with much of what you say in your statement. Critically,
we agree that the U.S. must seek a change in the current ISO direction.
But we feel that your statement does not make sufficiently clear those
responsibilities which lead the X3J13 committee to this position. X3J13
is the committee we are most familiar with. We believe that the IEEE
group working standardization of Scheme may have similar concerns, but
we do not presume to speak for them.
The X3J13 effort is quite mature. We have almost finished the standard
we are chartered to develop. Most technical decisions have been made,
and the ones that remain to be made have already received significant
discussion and study. Editorial work to produce the standards document
is already well underway.
A number of individuals and companies have devoted significant time and
resources to creating the X3J13 Common Lisp standard. An even larger
number of individuals and companies have devoted resources to preparing
themselves to use this standard. The X3J13 committee has a significant
commitment to these individuals and companies; we must finish the
language we set out to create, and must follow through on our commitment
to making it an ANSI standard.
An important part of this commitment is that we cannot at this point
take any action which would diminish the value the standard we have
worked so hard to create. This responsibility constrains our options in
working with the ISO standardization effort. These constraints can be
complex and difficult to understand. This accounts in part for the time
it has taken the U.S. delegation to develop this position statement.
But one such constraint is now clear: The X3J13 committee cannot
endorse the development of an ISO standard which is as similar to Common
Lisp as ISLisp is currently. An ISO standard which is targeted that
close to the Common Lisp language being developed by X3J13, should be
exactly the same that being developed by X3J13.
The existence of a similar but separate ISO standard would significantly
weaken the ANSI Common Lisp standard. Problems would be caused by
policies that mandate the use of ISO standards over ANSI standards;
perhaps these problems could be resolved, but it would take time. It is
precisely to avoid those kinds of problems that our "constituency" has
chartered us to develop ANSI Common Lisp.
In addition, there would be widespread confusion among educators,
authors, application vendors and others about which Common Lisp was the
standard one. The technical leaders of the X3J13 effort would be
rightly criticized for not being committed to the language they created.
The United States is, however, part of the ISO Lisp standardization
process. As part of that process we must decide how to resolve the
obligations we are under to our X3J13 constituency with the obligations
that other delegations have to their constituencies. We would like to
try and do so in the most generous and equitable way possible. At this
point, it appears that the idea of multiple ISO standards is the best
solution.
One of these ISO standards would be the language currently being
specified by the X3J13 committee. This could be called ISO Common Lisp.
We would of course actively encourage additional cleanup proposals to
ensure that the language is in fact suitable for use as an international
standard. An important part of this is the commitment to working out
the character set proposal.
Other ISO standards could be developed for other specific purposes.
Those standards would have to be sufficiently different from ISO Common
Lisp that they would not diminish that standard. It might be possible
to develop a strict subset of ISO Common Lisp, but we do not believe it
is possible do so in a short timeframe.
We understand, and we believe the entire X3J13 committee understands,
that this position may be perceived as inflexible by certain other
members of the ISO committee. We would ask those members to consider
the commitment we have to the individuals and companies which have
plans to use X3J13 Common Lisp. We simply cannot take an action which
would compromise that commitment.
Daniel G. Bobrow
Scott Fahlman
Gregor Kiczales
Larry Masinter
-------
∂02-Nov-88 1836 emma@csli.Stanford.EDU CSLI Calendar, November 3, 4:7
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Nov 88 18:36:32 PST
Received: by csli.Stanford.EDU (4.0/4.7); Wed, 2 Nov 88 17:28:12 PST
Date: Wed, 2 Nov 88 17:28:12 PST
From: emma@csli.Stanford.EDU (Emma Pease)
To: friends@csli.Stanford.EDU
Subject: CSLI Calendar, November 3, 4:7
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
3 November 1988 Stanford Vol. 4, No. 7
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 3 November 1988
12 noon TINLab
Cordura Hall What is Planning? What does it have to do with
Conference Room Language Processing?
Ray Perrault
(rperrault@ai.sri.com)
Abstract in last week's Calendar
2:15 p.m. CSLI Seminar
Cordura Hall Week 6: Knowledge-based Approaches to the
Conference Room Resolution Problem
Jerry Hobbs
(hobbs@warbucks.ai.sri.com)
Abstract in last week's Calendar
3:45 p.m. Tea
Ventura Hall
____________
CSLI ACTIVITIES FOR NEXT THURSDAY, 10 November 1988
12 noon TINLecture
Cordura Hall Higher-Level Lexical Structure and Parsing
Conference Room Michael Tanenhaus
University of Rochester
(mtan@prodigal.psych.rochester.edu)
Abstract below
2:15 p.m. CSLI Seminar
Cordura Hall Week 7: Premature Commitments in Language Resolution
Conference Room Higher-Level Lexical Structure and Parsing Resolution
Michael Tanenhaus
University of Rochester
(mtan@prodigal.psych.rochester.edu)
3:45 p.m. Tea
Ventura Hall
____________
NEXT WEEK'S TINLECTURE
Higher-Level Lexical Structure and Parsing
Michael Tanenhaus
University of Rochester
(mtan@prodigal.psych.rochester.edu)
November 10
Sentences with long-distance dependencies (filler-gap sentences)
present interesting problems of ambiguity resolution. This paper will
present results from a series of experiments, using both behavioral
measures and brain-evoked potential measures, that provide a detailed
picture of how people use verb argument structure and verb control
information to posit and fill gaps. The results provide intriguing
suggestions about the interaction among syntactic, semantic, and
lexical information in parsing.
____________
TALK
Minds, Machines, and Searle
Stevan Harnad
(harnad@princeton.edu)
Thursday, 3 November, 10:00
Cordura Hall Conference Room
Searle's provocative "Chinese Room Argument" attempted to show that
the goals of "Strong AI" are unrealizable. Proponents of Strong AI
are supposed to believe that (i) the mind is a computer program, (ii)
the brain is irrelevant, and (iii) the Turing Test is decisive.
Searle's point is that since the programmed symbol-manipulating
instructions of a computer capable of passing the Turing Test for
understanding Chinese could always be performed instead by a person
who could not understand Chinese, the computer can hardly be said to
understand Chinese. Such "simulated" understanding, Searle argues, is
not the same as real understanding, which can only be accomplished by
something that "duplicates" the "causal powers" of the brain. In this
paper I make the following points:
1. Simulation versus Implementation
2. Theory-Testing versus Turing-Testing
3. The Convergence Argument
4. Brain Modeling versus Mind Modeling
5. The Modularity Assumption
6. The Teletype versus the Robot Turing Test
7. The Transducer/Effector Argument
8. Robotics and Causality
9. Symbolic Functionalism versus Robotic Functionalism
10. "Strong" versus "Weak" AI
∂02-Nov-88 1849 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu NSF support for algorithms and parallel computing systems
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Nov 88 18:48:56 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA25170; Wed, 2 Nov 88 15:53:08 PDT
Message-Id: <8811022353.AA25170@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 2 Nov 88 15:53:01 PST
Received: by BYUADMIN (Mailer R2.01) id 1659; Wed, 02 Nov 88 16:49:21 MST
Date: Wed, 2 Nov 88 14:24:35 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Errol Lloyd <elloyd@NOTE.NSF.GOV>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Errol Lloyd <elloyd@NOTE.NSF.GOV>
Subject: NSF support for algorithms and parallel computing systems
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
PRELIMINARY ANNOUNCEMENT
Beginning in FY89, NSF and DARPA will jointly support research projects
in the area of algorithm design, analysis and instrumentation for parallel
computing systems. The purpose of the program is to promote closer ties
between theory and practice. By enabling the highest quality efforts to
operate at an increased scale, the program aims to encourage collaborative
efforts that link theoretical computer science with experimentation and
engineering. Specific focal points are:
Parallel algorithms and computational models,
Analysis and instrumentation techniques for complex parallel models,
Parallel algorithm design paradigms, and
Design paradigms for parallel artificial intelligence algorithms.
The research proposed under this joint program should investigate
innovative approaches and techniques that may lead to revolutionary advances
in the state of the art. Specifically excluded are approaches that are
primarily incremental improvements to the existing state of practice.
Specific areas of interest include, but are not limited to, the following:
Parallel algorithms and data structures,
Probabilistic and randomized algorithms,
Parallel models of computation including cellular automata,
Computational geometry,
Algorithm design paradigms,
Mechanizable algorithm analysis techniques,
Instrumentation techniques,
Very high level languages for expressing parallel algorithms,
Quantitative analysis methods for heuristics, and
Design paradigms for algorithms in vision, speech, planning and learning.
Excluded from this program is work of a primarily foundational nature in
structural complexity, combinatorial mathematics and algorithm analysis, as
well as primarily application-specific algorithm design and implementation.
Approximately $1.5 Million will be awarded in FY89. Proposals for efforts
of any size will be considered. In general, support will be provided for
principal investigators, graduate students, postdoctoral research support, and
specialized equipement necessary for the conduct of the research, as well as
other funds normally allowed in an award. Proposals under this program will
be subject to the normal NSF peer review process. Special emphasis in the
review process will be given to the value gained from team research and the
capability of the plan for achieving transition of results into the research
and/or industrial communities. NSF and DARPA staffs will make final selections
from meritorious proposals. Proposals should be submitted to NSF as if they
were regular NSF submissions (for consideration by: NSF-DARPA Parallel
Computing Initiative, CCR-CISE). For technical information, prospective PIs
may contact either NSF or DARPA program offices:
DARPA - Dr. William L. Scherlis, Program Manager, Defense Advanced
Research Projects Agency, (202) 694-5800, scherlis@vax.darpa.mil
NSF - Dr. Errol L. Lloyd, Division of Computer and Computation Research,
(202) 357-7375, elloyd@note.nsf.gov
Target date for submitting proposals is December 19, 1988.
∂02-Nov-88 1902 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu PODC Call for Papers:
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Nov 88 19:02:35 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA25736; Wed, 2 Nov 88 16:03:47 PDT
Message-Id: <8811030003.AA25736@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 2 Nov 88 16:03:40 PST
Received: by BYUADMIN (Mailer R2.01) id 2187; Wed, 02 Nov 88 17:02:10 MST
Date: Wed, 2 Nov 88 14:29:15 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Michael Merritt <mischu@ALLEGRA.ATT.COM>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Michael Merritt <mischu@ALLEGRA.ATT.COM>
Subject: PODC Call for Papers:
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
______________________________________________________________________
CALL FOR PAPERS
Eighth ACM SIGACT-SIGOPS Symposium on
Principles of Distributed Computing
*************
* (PODC'89) *
*************
August 14-16, 1989
Edmonton, Alberta, Canada
Original research contributions are sought that address fundamental
issues in the theory and practice of distributed and concurrent
systems. Topics of interest include, but are not limited to:
- Principles of distributed computation derived from
practical experience with working systems
- Algorithms and complexity
- Specification, semantics, and verification
- Programming languages and programming language constructs
- Fault tolerance
- Cryptography and security
Important dates:
Jan. 30, 1989 Abstracts due
Apr. 1, 1989 Acceptance notification
May 15, 1989 Camera-ready version due
Please send 4 copies of a detailed abstract (not the complete paper),
with the address, e-mail address, and telephone number, to the Program
Chair:
Michael Merritt
AT&T Bell Laboratories
Room 3D-458
600 Mountain Avenue
Murray Hill, NJ 07974
U.S.A.
e-mail: allegra!mischu
The abstract must provide sufficient details to allow the program
committee to assess the merits of the paper and should include
appropriate references to and comparisons with literature. It is
recommended that each submission begin with a succinct statement of
the problem, a summary of the main results, and a brief explanation of
the significance and relevance to the conference, all suitable for a
non-specialist. Technical development of the work, directed to the
specialist, should follow. A limit of 10 typed double-spaced pages is
placed on submissions. If the authors believe that more details are
essential to substantiate the main claims of the paper, they are
encouraged to include a clearly marked appendix that will be read at
the discretion of the Program Committee.
Abstracts conforming to the guidelines will be considered by the
committee if they are postmarked by the deadline of January 30th,
1989, and are received within a reasonable time thereafter.
The Program Committee:
Yehuda Afek, AT&T and Tel Aviv University
Baruch Awerbuch, MIT
Edmund Clarke, Carnegie Mellon
Cynthia Dwork, IBM
Michael Fischer, Yale University
Mohamed Gouda, Univ. of Texas at Austin
Maurice Herlihy, Carnegie Mellon
Michael Merritt, AT&T
David Peleg, Weizmann Institute, Israel
Charles Rackoff, University of Toronto
Peter Weinberger, AT&T
Pierre Wolper, University of Liege, Belgium
Conference Chair:
Piotr Rudnicki, The University of Alberta, Edmonton, Canada,
(piotr@alberta.UUCP)
Publicity Chair:
M. Tamer Ozsu, The University of Alberta, Edmonton, Canada,
(ozsu@alberta.UUCP)
______________________________________________________________________
Note: the printed call for papers has an error in one reference to the date:
January 30 is the REAL deadline. M. Merritt
∂03-Nov-88 0923 TAJNAI@Score.Stanford.EDU Call for Papers for Computer Forum
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Nov 88 09:23:01 PST
Date: Thu 3 Nov 88 09:12:14-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Call for Papers for Computer Forum
To: phd@Score.Stanford.EDU, csl-students@Sierra.Stanford.EDU
cc: faculty@Score.Stanford.EDU, hayes-roth@SUMEX-AIM.Stanford.EDU
Message-ID: <12443639304.17.TAJNAI@Score.Stanford.EDU>
TO: CSD/CSL PHD Students
CC: CSD/CSL Faculty
FROM: Carolyn Tajnai, Director
Edward Feigenbaum, Program Chairman
SUBJECT: Call for Papers, Stanford Computer Forum 21st Annual Meeting,
February 15/16, 1989
PHD students are invited to submit a title and one-page abstract
describing their research. It is important that faculty advisors
review proposed talks prior to submission.
The following information should be included:
1. Research area
2. Name of faculty advisor
3. Date of expected graduation
The program committee will review the abstracts and make selections.
Priority will be given to students who expect to graduate in 1989.
DEADLINE FOR SUBMISSION: Monday, November 28
Papers should be submitted to the Computer Forum, ERL 450 or sent online
to Tajnai@Score.
-------
∂03-Nov-88 1033 @Score.Stanford.EDU:eaf@ksl.stanford.edu Re: Call for Papers for Computer Forum
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Nov 88 10:32:26 PST
Received: from ksl.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 3 Nov 88 10:28:09-PST
Received: by ksl.stanford.edu (4.0/inc-1.0)
id AA28580; Thu, 3 Nov 88 10:29:35 PST
Date: Thu, 3 Nov 1988 10:29:34 PST
From: Edward Feigenbaum <eaf@ksl.stanford.edu>
To: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Cc: phd@Score.Stanford.EDU, csl-students@Sierra.Stanford.EDU,
faculty@Score.Stanford.EDU, hayes-roth@SUMEX-AIM.Stanford.EDU,
tajnai@score.stanford.edu
Subject: Re: Call for Papers for Computer Forum
In-Reply-To: Your message of Thu 3 Nov 88 09:12:14-PST
Message-Id: <CMM.0.88.594584974.eaf@ksl.stanford.edu>
Dear faculty and student colleagues,
As a followup to Carolyn's message:
We have a large and enthusiastic Computer Forum industrial affiliates
membership. This constitutes a very important financial support pool, and
a very large job pool for our graduate students. We would like to have
maximum student participation in making the February event really
informative and excellent.
All students with worthy material will be invited to present their material
at poster sessions (with one-on-one interaction with affiliate attendees).
The most worthy of the proposed presentations will be invited to deliver
talks to the assembled groups in sessions.
We are also looking for maximum faculty participation in giving talks at
the sessions.
So please get involved! And send me or Carolyn your proposed presentations.
We want to make this an excellent Forum meeting in February.
Best wishes,
Ed Feigenbaum, Program Chairman
∂03-Nov-88 1419 @polya.Stanford.EDU:tah@linz.stanford.edu MTC Seminar
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Nov 88 14:19:41 PST
Received: from linz.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA17255; Thu, 3 Nov 88 14:18:42 PDT
Received: by linz.stanford.edu (5.59/SMI-DDN)
id AA00252; Thu, 3 Nov 88 14:17:29 PDT
Message-Id: <8811032217.AA00252@linz.stanford.edu>
To: lop@polya.stanford.edu
Subject: MTC Seminar
Date: 03 Nov 88 14:17:17 PST (Thu)
From: Tom Henzinger <tah@linz.stanford.edu>
Friday, Nov. 4, 12 noon, MJH 301:
Brian Howard will present Plotkin's "Call-by-name, Call-by-value and the
Lambda-Calculus" (TCS 1, 1975). Copies of the paper can be picked up
from Rosemary, MJH 340.
∂03-Nov-88 1531 snoeyink@polya.Stanford.EDU Thesis proposal presentation 4pm Monday, Nov 7
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Nov 88 15:31:18 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA22398; Thu, 3 Nov 88 15:31:06 PDT
Date: Thu, 3 Nov 88 15:31:06 PDT
From: Jack Snoeyink <snoeyink@polya.Stanford.EDU>
Message-Id: <8811032331.AA22398@polya.Stanford.EDU>
To: aflb-su@polya.Stanford.EDU
Subject: Thesis proposal presentation 4pm Monday, Nov 7
I will be presenting my thesis proposal at 4pm on Monday, Nov. 7 in
room 252. The stanford aflb crowd is hereby invited to come and
heckle.
Jack
Title: Sweeping Arrangements of Curves
Abstract: Many graphics algorithms employ a sweep paradigm to convert
a static geometry problem into a dynamic problem of lower dimension.
For example, you can determine the intersections of a set of lines in
the plane by sweeping the plane with another line. Edelsbrunner and
Guibas developed a more efficient algorithm by relaxing the
straightness condition on the sweep---they sweep the plane with a
`pseudoline,' a curve that intersects each line once.
Mathematicians since Levi in 1926 have studied arrangements of
pseudolines to learn more about arrangements of lines. Recently
Sharir and others have looked at curves that intersect in at most $k$
points and have developed a theory of Davenport-Shinzel sequences.
I will talk about sweeping arrangements of $k$-intersecting
curves---specifically, the fact that you can sweep an arrangement of
such curves with a curve that maintains the $k$ intersection property
iff $k<3$. I will use this result to give a new proof of Levi's
extension lemma for pseudolines and to prove it for 2-intersecting
curves. And I will indicate how these results may lead to algorithms.
∂04-Nov-88 1135 BSCOTT@Score.Stanford.EDU AFOSR Booklet
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Nov 88 11:35:10 PST
Date: Fri 4 Nov 88 11:29:05-PST
From: Betty Scott <BSCOTT@Score.Stanford.EDU>
Subject: AFOSR Booklet
To: Faculty@Score.Stanford.EDU
cc: Bscott@Score.Stanford.EDU
Message-ID: <12443926361.15.BSCOTT@Score.Stanford.EDU>
Just received from SPO a booklet on Research Interests of the AFOSR. It's
in my office if you're interested in seeing it.
Betty
-------
∂04-Nov-88 1255 hoffman@csli.Stanford.EDU Symbolic Systems Forum
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Nov 88 12:55:22 PST
Received: by csli.Stanford.EDU (4.0/4.7); Fri, 4 Nov 88 12:38:27 PST
Date: Fri 4 Nov 88 12:38:25-PST
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: Symbolic Systems Forum
To: forum-faculty@csli.Stanford.EDU, ssp-forum@csli.Stanford.EDU
Message-Id: <594679106.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
As announced previously, the Symbolic Systems Forum has been cancelled for
the Kant Lecture given by David Lewis. (In other words, our speaker/
major participant had to attend the Kant Lecture.)
Next week Barwise and Etchemendy will speak on Logic and Information
in Symbolic Systems. The week after will be the Symbolic Systems
Internship Forum.
More detail on these in later messages.
-------
∂04-Nov-88 1349 PATRICIA@Score.Stanford.EDU Luncheon
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Nov 88 13:49:41 PST
Date: Fri 4 Nov 88 13:46:47-PST
From: Patricia Pestalozzi <PATRICIA@Score.Stanford.EDU>
Subject: Luncheon
To: faculty@Score.Stanford.EDU
cc: patricia@Score.Stanford.EDU
Message-ID: <12443951428.38.PATRICIA@Score.Stanford.EDU>
Hi,
We are planning a luncheon for undergraduate women interested
in computer science. I am looking for some faculty that would
be interested in coming to the luncheon and talking to the undergrads.
Would you be interested? We are planning it for Thursday, December the 1st,
from 11:45 to 2:00, at the faculty club.
Please let me know if you can make it by Thursday, November 10.
Hope you can make it!
Patricia
-------
∂04-Nov-88 1517 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU FAX Machine
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Nov 88 15:17:45 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 4 Nov 88 15:13:57-PST
Message-ID: <1rryGG@SAIL.Stanford.EDU>
Date: 04 Nov 88 1512 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: FAX Machine
To: faculty@Score.Stanford.EDU, staff@Score.Stanford.EDU
Reply-To: ARK@SAIL.STANFORD.EDU
The CS dept is contemplating getting a FAX machine. You're probably
not surprised that I've taken on the role of coordinating the recommendation
process. So if you have preferences, recommendations, or requirements
for FAX machine features, brands, or models, please let me know. Thanks.
Arthur
∂07-Nov-88 0639 X3J13-mailer Re: Proposed US Position Statement
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 7 Nov 88 06:38:55 PST
Date: 7 Nov 1988 09:37-EST
Sender: ROSENKING@A.ISI.EDU
Subject: Re: Proposed US Position Statement
From: ROSENKING@A.ISI.EDU
To: Gregor.pa@XEROX.COM
Cc: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU] 7-Nov-88 09:37:07.ROSENKING>
In-Reply-To: <19881103000503.4.GREGOR@PORTNOY.parc.xerox.com>
I wish to extend my support to the comments made by Bobrow et al, in
reference to Dick Gabriel's Proposed US Position Statement. I have
volunteered my time, effort and company's support to assist in
developing a Common Lisp standard. Each individuals participation in
X3J13 constitutes a major investment in Common Lisp. I agree that we
should protect our investment and thereby support this proposal.
Jeff Rosenking
∂07-Nov-88 0930 ruben@apple.com Re: Symbolic Systems Forum Oct. 21 (Friday)
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Nov 88 09:29:54 PST
Received: from apple.com by csli.Stanford.EDU (4.0/4.7); Mon, 7 Nov 88 09:22:50 PST
Received: by apple.com (5.59/25-eef)
id AA05579; Mon, 7 Nov 88 09:17:37 PST
Date: Mon, 7 Nov 88 09:17:37 PST
From: Ruben Kleiman <ruben@apple.com>
Message-Id: <8811071717.AA05579@apple.com>
To: HOFFMAN@CSLI.Stanford.EDU, forum-faculty@csli.Stanford.EDU
Subject: Re: Symbolic Systems Forum Oct. 21 (Friday)
Thanks for your note. My preference would be to speak on March (
(or in that vecinity).
Thanks,
Ruben Kleiman
∂07-Nov-88 1129 TAJNAI@Score.Stanford.EDU Call for nominations for Bell Fellowship
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Nov 88 11:29:48 PST
Date: Mon 7 Nov 88 11:22:40-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Call for nominations for Bell Fellowship
To: faculty@Score.Stanford.EDU
cc: bscott@Score.Stanford.EDU, hemenway@Score.Stanford.EDU,
bergman@Score.Stanford.EDU
Message-ID: <12444711624.36.TAJNAI@Score.Stanford.EDU>
We have received the call for nominations of 3 CSD PHD students --
must be US citizens or have permanent residency. Please send the
nomations to me; last day for nominations is Monday, Nov. 28.
The Bell Fellowship is a 4-year fellowship. Most appropriate students
are second year students who have passed the comprehensive. Those who
have passed the qual make excellent candidates.
We will nominate 3 students and only 1 will receive the fellowship, so they
will be competing against one another.
Carolyn Tajnai
-------
∂07-Nov-88 1429 vavasis@polya.Stanford.EDU bats is THIS FRIDAY!!
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Nov 88 14:29:39 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA19518; Mon, 7 Nov 88 14:28:40 PDT
Date: Mon, 7 Nov 88 14:28:40 PDT
From: Stephen A. Vavasis <vavasis@polya.Stanford.EDU>
Message-Id: <8811072228.AA19518@polya.Stanford.EDU>
To: aflb-su@polya.Stanford.EDU
Subject: bats is THIS FRIDAY!!
BATS is coming up this Friday (Nov 11) at IBM Almaden. Apparently,
IBM forgot to invite Stanford, because I heard about it through the
Berkeley mailing list. If you want to go, tell the Stanford BATS
coordinator (I don't know who the current Stanford BATS coordinator
is.)
I think that we should rename our next AFLB as "bats" and then not
invite anybody!
Here are the abstracts:
From @Score.Stanford.EDU:irani@ernie.Berkeley.EDU Mon Nov 7 14:00:06 1988
Return-Path: <@Score.Stanford.EDU:irani@ernie.Berkeley.EDU>
Received: from Score.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA16626; Mon, 7 Nov 88 14:00:04 PDT
Received: from ernie.Berkeley.EDU by SCORE.STANFORD.EDU with TCP; Mon 7 Nov 88 13:53:37-PST
Received: by ernie.Berkeley.EDU (5.61/1.29)
id AA19282; Mon, 7 Nov 88 11:25:18 PST
Date: Mon, 7 Nov 88 11:25:18 PST
From: irani@ernie.Berkeley.EDU (Sandy Irani)
Message-Id: <8811071925.AA19282@ernie.Berkeley.EDU>
To: theory@ernie.Berkeley.EDU
Subject: BATS Announcement
Status: R
Here are the program, abstracts and directions to the next BATS
which is at IBM, November 11.
10 AM Nearly Linear Time
Yuri Gurevich, University of Michigan
(This year with Stanford and IBM Almaden Center)
11 AM Cryptographic key distribution and computational number theory
Kevin S. McCurley, (IBM Almaden).
12 PM Lunch
1:30 PM
On the Time and Space Complexity of Computation Using Write-Once Memory
-OR-
Is Pen Really Much Worse Than Pencil?
Ronitt Rubinfeld
UC Berkeley
2:30 PM Moni Naor (UC Berkley and IBM Almaden)
UNIVERSAL ONE-WAY HASH FUNCTIONS AND THEIR CRYPTOGRAPHIC APPLICATIONS
=====================================================================
ABSTRACTS
Nearly Linear Time
Yuri Gurevich, University of Michigan
(This year with Stanford and IBM Almaden Center)
Linear time computability is badly dependent on the machine model. In
this connection, we examined arguments in favor of the robustness of
Polynomial Time and found an attractive and relatively modest
extension of the ill-defined Linear Time that we call NL or Nearly
Linear Time. We will present arguments in favor of the great
robustness of NL, give a machine-independent definition of NL, compare
Nearly Linear Time with the Quasilinear Time of Schnorr and exhibit an
NL-complete problem. [This is a joint work with Saharon Shelah.]
=========================================================================
Cryptographic key distribution and computational number theory
Speaker: Kevin S. McCurley
Abstract: There are numerous cryptosystems that have their security
based on the presumed difficulty of computational problems in number
theory. In particular, variations of the Diffie and Hellman key
distribution scheme have been proposed that rely on the difficulty of
discrete logs in various groups, on the difficulty of factoring
integers, and on the difficulty of computing the class number of an
imaginary quadratic number field. In this talk I will describe how
these schemes work, what the underlying computational problems are,
and what the current state of knowledge is concerning the complexity
of the underlying computational problems. This talk is intended to be
accessible to the nonspecialist.
=========================================================================
On the Time and Space Complexity of Computation Using Write-Once Memory
-OR-
Is Pen Really Much Worse Than Pencil?
Ronitt Rubinfeld
UC Berkeley
ABSTRACT
We introduce a model of computation based on the use of write-once
memory. Write-once memory has the property that bits may be set but
not reset. Our model consists of a RAM with a
small amount (such as logarithmic or $n sup alpha$ for $ alpha < 1$) of
regular memory, and a polynomial amount of write-once memory.
Bounds are given on the time required to simulate on write-once memory
algorithms which originally run on a RAM with a polynomial amount of
regular memory. We attempt to characterize algorithms that can be
simulated on our write-once memory model with very little slow-down. The
space requirements of algorithms running on the write-once model are studied.
We show that general simulations of algorithms originally running on a
RAM with regular memory by algorithms running on our write-once memory model
require space proportional to the number of steps simulated. In order to
study the space complexity further, we define an analogue of the pebbling
game, called the pebble-sticker game. A sticker is different from a pebble
in that it cannot be removed once placed on a node of the computation graph.
As placing pebbles correspond to writes to regular memory, placing stickers
correspond to writes to the write-once memory. Tight bounds are shown on
pebble-sticker tradeoffs required to evaluate trees and planar graphs.
Finally, we define the complexity class WO-PSPACE as the class of problems
which can be solved with a polynomial amount of write-once memory and a
logarithmic amount of regular memory, and show that it is equal to P.
This is joint work with Sandy Irani and Moni Naor
=========================================================================
Moni Naor
UNIVERSAL ONE-WAY HASH FUNCTIONS AND THEIR CRYPTOGRAPHIC APPLICATIONS
We define a Universal One-Way Hash Function Family, a primitive which
enables the compression of elements in the function domain. The main
property of this new primitive is that given an element x in the domain,
it is computationally hard to find a different domain element which
collides with x. We prove constructively that Universal One-Way Hash
Functions exist if 1-1 One-Way Functions exist.
The main application and motivation of the primitive is a Secure Digital
Signature Scheme which can be based on the existence of any 1-1
One-Way functions;
the system is secure against the most general attack known.
Previously, all Secure Signature Schemes were based on a more specific
mathematical assumption, that Trapdoor One-Way Functions exist.
Another application is public fingerprints of a file - a small amount of
securely stored data allows users to verify that the content of a file
was not changed. This can be used, for instance, to check whether
programs were effected by computer viruses.
Joint work with Moti Yung
=============================================================
Directions.
If you are coming on 101 take the Bernal exit (south of San Jose).
Go on Bernal road
to the west as far as you can. You reach a hill, continue on the
same road entering Santa Theresa Park. Go through the winding mountain
road of the park until you reach IBM. Come in through the main entrance
and register at the receptionist. (You will get a vistors badge).
Auditorium A is very close to the entrance.
∂07-Nov-88 1453 STAGER@Score.Stanford.EDU Final exams
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Nov 88 14:50:14 PST
Date: Mon 7 Nov 88 14:37:20-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: Final exams
To: faculty@Score.Stanford.EDU, loomans@Score.Stanford.EDU,
stewart@Polya.Stanford.EDU, chou@Polya.Stanford.EDU,
tah@Polya.Stanford.EDU, plambeck@Polya.Stanford.EDU, jk@Sail.Stanford.EDU,
yao.pa@Xerox.COM, koch@Polya.Stanford.EDU
cc: stager@Score.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12444747062.23.STAGER@Score.Stanford.EDU>
It's time again to start planning for final exams. (Refer to page 6
of the Autumn Quarter Time Schedule if you have questions about Dead Week
policy, or what the examination schedule is.)
Please respond to the following by FRIDAY, NOVEMBER 11:
1. Have you moved to a new room/time (and not let me know)? If so, where
and when are you meeting now?
2. Are you giving a take-home exam instead of an in-class exam?
Do you plan on giving a final exam this quarter?
3. Will you need additional space in order to provide alternate seating?
If so, how many TOTAL seats will you be requiring?
4. Are you giving an alternate exam in addition to your regularly scheduled
exam? If so what day/time, and what size of a room will you be needing?
Please Note:
"Classes starting at unusual times (e.g. 2:30pm or 2:45pm)hold exams in the
same time slots as classes starting at the regular time with the same hour
designation. So, the final examination in the examples above would be given
under the 2:15 time slot."
Contact me at Stager@Score, or 3-6094, if you have any questions.
Thanks.
Claire
-------
∂07-Nov-88 1507 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Facutly Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Nov 88 15:07:34 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 7 Nov 88 15:03:31-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA22654; Mon, 7 Nov 88 15:04:20 PDT
Date: Mon, 7 Nov 1988 15:03:48 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score
Cc: bureaucrats@polya.Stanford.EDU
Subject: Facutly Lunch
Message-Id: <CMM.0.87.594947028.chandler@polya.stanford.edu>
Just to be sure my earlier message got through......there will be a faculty
lunch tomorrow at 12:15 in MJH-146 - no agenda item - no Nils (he's out of
town)....just come and enjoy!
∂07-Nov-88 1517 X3J13-mailer US Position Statement (Version 2)
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I'd like to thank the following people for providing helpful comments
about my proposed US Position Statement:
Danny Bobrow, Kathy Chapman, Will Clinger, Linda DeMichiel, Patrick
Dussud, Scott Fahlman, Chris Haynes, Jim Kempf, Gregor Kiczales, Thom
Linden, Larry Masinter, Dave Moon, Kent Pitman, Guy Steele, and JonL
White.
As I've mentioned before, I am your representative, and my job is to
represent your position at the ISO meetings. The following the is current
(and I presume the final) position statement:
**************************************************************************
The US is currently undertaking two standardization efforts in Lisp:
X3J13 is standardizing Common Lisp for ANSI, and IEEE is standardizing
Scheme. The US believes that these two efforts cover a wide range of
concerns and uses for Lisp: Scheme is small, elegant, and
mathematically well-founded, and Common Lisp is full-featured, mature,
and commercially viable. Within the United States, there is no demand
for another Lisp standard at this time.
The current activity of WG16 is to develop a standard for a dialect of
Lisp directed at a community of users who are served neither by Common
Lisp nor by Scheme---that dialect is IsLisp. Although IsLisp will not
be of major importance within the US, the US supports the IsLisp
standardization effort as long as it does not negatively affect
standards for other dialects of Lisp. In particular, the US feels
that it is important not to have two standardized dialects of Lisp
that are nearly identical unless one is a strict subset of the other.
Having two such similar but different dialects weakens the position of
users who have come to depend on one of the dialects.
The US believes that the primary focus of standardization is to codify
existing practice to support the creation and delivery of portable
software. Thus, the major focus of the US standardization efforts is
to provide stability to the community of Common Lisp and Scheme users.
Of secondary importance are the invention of new Lisp dialects and the
standardization of Lisp dialects or features not in common usage. The
US therefore agrees with the ISO goal of a near term standard in the
1990 time frame along with longer range consideration of future
dialects and features.
Common Lisp is in wide use in Europe, Japan, and Australia.
Implementations of Common Lisp are under way in the UK, Germany,
Italy, and Japan (and possibly other countries). In each of these
countries there are companies whose customers depend on portable
software written in Common Lisp. The future of these companies
thus depends on having a Common Lisp standard. Furthermore, it is
common for various US funding agencies to require projects to be
undertaken in ISO languages when they are available. Just as it would
be unfair for Common Lisp to be imposed by law in contexts where it is
not wanted, so it would be unfair for IsLisp to be imposed within the
US.
For these reasons, the US proposes that WG16 produce a draft standard
for ISO Common Lisp. As IsLisp is aimed at satisfying certain needs
for a specific community, so ISO Common Lisp would be aimed at
satisfying the Common Lisp needs for the international Common Lisp
community. The US wishes to reserve the right to request that WG16
produce a draft standard for ISO Scheme.
The US believes that Common Lisp is a valid candidate for
international standardization both because it is used internationally
and also because it is a mature and stable dialect. Common Lisp has
been under design and specification for 8 years. Commercial quality
implementations of Common Lisp have been available for 4 years. It
has been shown that small memory Common Lisp implementations are
possible and that small applications can be delivered: The key to
small applications lies more in implementation technology and the
environment than in language design. The near term standardization of
ISO Common Lisp would have substantial positive impact on the
acceptance of existing commercial Lisp implementations and of all
future Lisp dialects as vehicles for emerging applications.
The US believes that WG16 is the appropriate working group to
standardize Common Lisp. As determined at its first meeting, the
charter of WG16 endorses the standardization of multiple dialects of
Lisp. Therefore, WG16 can choose to produce draft standards for both
Common Lisp and IsLisp. It is not sufficient that there be only an
ANSI standard for Common Lisp because ANSI is not an international
standards organization.
The US feels that a draft standard for ISO Common Lisp could be
prepared by December 1989 with the assistance of X3J13. The US
proposes that WG16 request X3J13 to prepare the ISO draft standard for
Common Lisp. The ISO Common Lisp draft and the ANSI Common Lisp draft
should be identical.
Looking beyond Common Lisp, IsLisp, and Scheme, the US feels that an
important task for WG16 is working towards a next generation dialect
of Lisp, and this can be accomplished by drawing on the lessons learned
from existing dialects of Lisp.
∂07-Nov-88 2009 hoffman@csli.Stanford.EDU reminder
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Nov 88 20:09:00 PST
Received: by csli.Stanford.EDU (4.0/4.7); Mon, 7 Nov 88 20:02:35 PST
Date: Mon 7 Nov 88 20:02:35-PST
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: reminder
To: forum-faculty@csli.Stanford.EDU, ssp-forum@csli.Stanford.EDU
Message-Id: <594964955.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
As a reminder, the Forum always meets at 3:15.
If you need more explicit directions, contact me.
-------
∂07-Nov-88 2010 hoffman@csli.Stanford.EDU Symbolic Systems Forum Nov. 11
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Nov 88 20:10:08 PST
Received: by csli.Stanford.EDU (4.0/4.7); Mon, 7 Nov 88 19:59:43 PST
Date: Mon 7 Nov 88 19:59:42-PST
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: Symbolic Systems Forum Nov. 11
To: forum-faculty@csli.Stanford.EDU, ssp-forum@csli.Stanford.EDU
Message-Id: <594964783.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
This Friday (at long last), the Symbolic Systems Forum will renew
its weekly meetings. On Nov. 11 (this friday), Professor Jon
Barwise and Professor John Etchemendy will give a talk on "Logic
and Information in Symbolic Systems." The talk will be held in
Sweet Hall, room 026 (in the basement.) Sweet Hall is the
building between Stern Hall and Meyer Library.
Many cogntive scientists, though not all, take cognition to be
intrinsically symbolic. In particular, they view inference as symbol
manipulation. However, another view is that inference is the
extraction of information. How do these two views fit together?
The two of us are currently engaged in a project with SSP major Alan
Bush to build a computer system, Hyperproof, that allows the user to
reason by manipulating information, not symbols. The question is, how
can one get one's hands on information. To find out, come to our
talk.
Next week (Nov. 18), the Symbolic Systems Internship Forum will be
held: in it, each student and faculty sponser will discuss how
the summer project went. This Forum will be good for: (1) students
interested in obtaining Symbolic Systems Internships and (2) faculty
interested in having interns.
-------
∂08-Nov-88 1247 snoeyink@polya.Stanford.EDU bats rides
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Nov 88 12:47:48 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA18419; Tue, 8 Nov 88 12:47:23 PDT
Date: Tue, 8 Nov 88 12:47:23 PDT
From: Jack Snoeyink <snoeyink@polya.Stanford.EDU>
Message-Id: <8811082047.AA18419@polya.Stanford.EDU>
To: aflb-su@polya.Stanford.EDU
Subject: bats rides
I'm the bats coordinator, and the late notice is partially my fault.
Friday, Nov. 11, was chosen as the (tentative) date long ago, but
since I didn't get the abstracts until the same day Steve sent his
message, I forgot to publicize it. As penance, I'll try to arrange
rides.
If you are going and need a ride or can give people rides, please send
me mail (snoeyink@polya). Please tell me which talks you plan on
going to and how many can ride with you. Talks are at 10, 11, 1:30
and 2:30.
Directions.
If you are coming on 101 take the Bernal exit (south of San Jose). Go
on Bernal road to the west as far as you can. You reach a hill,
continue on the same road entering Santa Theresa Park. Go through the
winding mountain road of the park until you reach IBM. Come in through
the main entrance and register at the receptionist. (You will get a
vistors badge). Auditorium A is very close to the entrance.
o Jack
_/\_.
(')>-(`) snoeyink@polya.stanford.edu
∂08-Nov-88 1252 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu FCT 89
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Nov 88 12:52:40 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA18802; Tue, 8 Nov 88 12:52:13 PDT
Message-Id: <8811082052.AA18802@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 8 Nov 88 12:52:00 PST
Received: by BYUADMIN (Mailer R2.01) id 5820; Tue, 08 Nov 88 13:51:17 MST
Date: Tue, 8 Nov 88 11:17:46 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Subject: FCT 89
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
FUNDAMENTALS OF COMPUTATION THEORY - FCT 89
7th International Conference
will be held in Szeged, Hungary , August 21-25, 1989.
Major topics to be covered are :
Efficient Computation by Abstract Devices : Automata, Computability,
Probabilistic Computations, Parallel and Distributed Computing
Logics and Meanings of Programs : Algebraic and Categorical
Approaches to Semantics, Computational Logic, Logic Programming,
Verification, Program Transformations, Functional Programming
Formal Languages : Rewriting Systems, Algebraic Language Theory
Computational Complexity : Analysis and Complexity of Algorithms,
Design of Efficient Algorithms, Algorithms and Data Structures,
Computational Geometry, Complexity Classes and Hierarchies,
Lower bounds
The scientific program will include invited lectures and papers selected
by the Program Committee.
Conference Chairman : Ferenc Gecseg
Program Committee: G. Ausiello, J. Berstel, L. Budach, R. G.
Bukharajev, Phan Dinh Dieu, A. P. Ershov, F. Gecseg, J. Gruska,
J. Hartmanis, G. Hotz, K. Indermark, H. Jurgensen, M. Karpinski,
L. Lovasz, O. B. Lupanov, G. Mirkowska, A. Mostowski, A. Pultr,
J. H. Reif, G. Rozenberg, J. Sakarovitch, A. Salomaa, E. Szemeredi,
I. Wegener, Wu Wen - Tsun
Authors are invited to submit eight copies of a draft paper to the
Conference Chairman
by December 15, 1988.
Authors will be notified of acceptance or rejection
by April 1, 1989.
Deadline for final text :
May 15, 1989.
Address for correspondence:
FCT 89
Bolyai Institute
A. Jozsef University
Aradi v. tere 1.
6720 Szeged Hungary
Phone: 36-62-11622 Ext. 141
Telex: Hugary-82317
Organizing Committe : J. Demetrovics ( Chairman ) , Z. Esik
( Secretary ) , M. Bartha, J. Csirik, Gy. Horvath, J. Viragh
∂08-Nov-88 1719 gurevich@polya.Stanford.EDU bats rides
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Nov 88 17:19:07 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA09508; Tue, 8 Nov 88 17:18:03 PDT
Date: Tue, 8 Nov 88 17:18:03 PDT
From: Yuri Gurevich <gurevich@polya.Stanford.EDU>
Message-Id: <8811090118.AA09508@polya.Stanford.EDU>
To: snoeyink@polya.Stanford.EDU
Cc: aflb-su@polya.Stanford.EDU
In-Reply-To: Jack Snoeyink's message of Tue, 8 Nov 88 12:47:23 PDT <8811082047.AA18419@polya.Stanford.EDU>
Subject: bats rides
3 people can ride with me. I intend to attend all talks.
-Yuri Gurevich
∂08-Nov-88 1722 peters@russell.Stanford.EDU Stanford academic recruiting
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Nov 88 17:22:07 PST
Received: from localhost by russell.Stanford.EDU (4.0/4.7); Tue, 8 Nov 88 17:23:27 PST
To: ssp-faculty@russell.Stanford.EDU
Subject: Stanford academic recruiting
Date: Tue, 08 Nov 88 17:23:25 PST
From: peters@russell.Stanford.EDU
Fellow SSP faculty members,
This being Fall, Stanford's admissions folk are out telling high
school seniors what a wonderful university we have here. Day after
tomorrow, I'll be in Houston, where I graduated from high school, and
will take part in one of these sessions. Stanford's interdisciplinary
majors are one of its big attractions, and I plan to tell them about
Symbolic Systems. Perhaps some of you will soon be traveling
someplace where Admissions would like your help in attracting the best
and brightest undergraduates to Stanford. You might think about
offering them your assistance.
Stanley
∂08-Nov-88 1829 TAJNAI@Score.Stanford.EDU encourage students to send resumes to Forum
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Nov 88 18:28:52 PST
Date: Tue 8 Nov 88 18:27:13-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: encourage students to send resumes to Forum
To: faculty@Score.Stanford.EDU
cc: hiller@Score.Stanford.EDU, rlm@Score.Stanford.EDU,
eileen@Polya.Stanford.EDU
Message-ID: <12445051057.21.TAJNAI@Score.Stanford.EDU>
One of the important benefits of Computer Forum membership is resumes of
the students. We encourage the students to become involved as soon as
they get here and take advantage of the time they are students to get
acquainted with the Forum companies and researchers.
It is a big job collecting new resumes, updating those in the pipeline,
and moving those who have graduated into archive files. We have to get
the material to the printer before Thanksgiving in order to mail the books
before Christmas.
We need the help of the faculty in encouraging your PHD, MS and BS students
to participate in the program. Please ask each one of your students to
give this priority.
All CSD/CSL affiliated students are welcome, and that includes your
advisees in other majors (OR, ME, etc).
Carolyn
Bonnie Hiller (PHD and BS books)
Robert Miller (MS book)
-------
∂08-Nov-88 1908 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Faculty Lunch - 11/8/88
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Nov 88 19:08:37 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 8 Nov 88 19:06:49-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA02284; Mon, 7 Nov 88 11:36:54 PDT
Date: Mon, 7 Nov 1988 11:36:51 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score
Cc: bureaucrats@score
Subject: Faculty Lunch - 11/8/88
Message-Id: <CMM.0.87.594934611.chandler@polya.stanford.edu>
Just to remind you there will be a faculty lunch tomorrow at 12:15 in MJH146.
Even though Nils will be out of town, and there is no official agenda item,
Nils wanted me to invite you to come and enjoy!
∂09-Nov-88 1137 X3J13-mailer Official US Position
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
The following is the official US position statement, which was
hammered out by myself and the following people:
Danny Bobrow, Kathy Chapman, Will Clinger, Linda DeMichiel, Patrick
Dussud, Scott Fahlman, Chris Haynes, Jim Kempf, Gregor Kiczales, Thom
Linden, Larry Masinter, Dave Moon, Kent Pitman, Guy Steele, and JonL
White.
I'd like to especially thank Thom Linden and Gregor Kiczales with
whom I exchanged about 75 drafts over the last 24 hours.
*********************************************************************
The US is currently undertaking two standardization efforts in Lisp:
X3J13 is standardizing Common Lisp for ANSI, and IEEE is standardizing
Scheme. The US believes that these two efforts cover a wide range of
concerns and uses for Lisp: Scheme is small, elegant, and
mathematically well-founded, and Common Lisp is full-featured, mature,
and commercially viable. Within the United States, there is no demand
for another Lisp standard at this time.
The current activity of WG16 is to develop a standard for a dialect of
Lisp directed at a community of users who are served neither by Common
Lisp nor by Scheme---that dialect is IsLisp. Although is is unlikely
that IsLisp will have major near term commercial significance within
the US, the US supports the IsLisp standardization effort as long as
it does not negatively affect standards for other dialects of Lisp.
In particular, the US feels that it is important not to have two
standardized dialects of Lisp that are nearly identical unless one is
a strict subset of the other. Having two such similar but different
dialects weakens the position of users who have come to depend on one
of the dialects.
The US believes that the primary focus of standardization is to codify
existing practice to support the creation and delivery of portable
software. Thus, the major focus of the US standardization efforts is
to provide stability to the community of Common Lisp and Scheme users.
Of secondary importance are the invention of new Lisp dialects and the
standardization of Lisp dialects or features not in common usage. The
US therefore agrees with the ISO goal of a near term standard in the
1990 time frame along with longer range consideration of future
dialects and features.
Common Lisp is in wide use in Europe, Japan, and Australia.
Implementations of Common Lisp are under way in the UK, Germany,
Italy, and Japan (and possibly other countries). In each of these
countries there are companies whose customers depend on portable
software written in Common Lisp. The future of these companies thus
depends on having a Common Lisp standard.
The US believes that Common Lisp is a valid candidate for
international standardization both because it is used internationally
and also because it is a mature and stable dialect. Common Lisp has
been under design and specification for 8 years. Commercial quality
implementations of Common Lisp have been available for 4 years. It
has been shown that small memory Common Lisp implementations are
possible and that small applications can be delivered: The key to
small applications lies more in implementation technology and the
environment than in language design. The near term standardization of
ISO Common Lisp would have substantial positive impact on the
acceptance of existing commercial Lisp implementations and on the
viability of future Lisp dialects as vehicles for emerging
applications.
For these reasons, the US proposes the development of an ISO standard
for Common Lisp. Furthermore, the US proposes that WG16 request X3J13
to prepare the ISO draft standard for Common Lisp. The ISO Common
Lisp draft and the ANSI Common Lisp draft should be identical. The US
believes such a draft standard could be developed by December 1989.
The US also believes the development of an ISO standard for Common
Lisp is within the charter of WG16, which endorses the standardization
of multiple dialects of Lisp. At some point in the future, it may be
appropriate to develop an ISO standard for Scheme.
Looking beyond near term standardization, the US feels that an
important task for WG16 is working towards a next generation dialect
of Lisp, and this can be accomplished by drawing on the lessons
learned from existing dialects of Lisp.
∂09-Nov-88 1205 aaai@sumex-aim.stanford.edu test
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 9 Nov 88 12:05:40 PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA08686; Wed, 9 Nov 88 12:04:31 PST
Date: Wed, 9 Nov 1988 12:04:31 PST
From: AAAI <aaai@sumex-aim.stanford.edu>
To: officers:;@sumex-aim.stanford.edu
Cc: aaai@sumex-aim.stanford.edu
Subject: test
Message-Id: <CMM.0.88.595109071.aaai@sumex-aim.stanford.edu>
This is a test from our new account.
Thanks,
Claudia
∂09-Nov-88 1310 TAJNAI@Score.Stanford.EDU Please forward to CS professors.
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Nov 88 13:09:56 PST
Return-Path: <NA.PHL@Forsythe.Stanford.EDU>
Received: from forsythe.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 9 Nov 88 12:48:48-PST
Date: Wed, 9 Nov 88 12:48:29 PST
To: tajnai@score
From: "Portia Leet" <NA.PHL@Forsythe.Stanford.EDU>
Subject: Please forward to CS professors.
ReSent-Date: Wed 9 Nov 88 13:07:23-PST
ReSent-From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
ReSent-To: faculty@Score.Stanford.EDU, phd@Score.Stanford.EDU,
ras@Score.Stanford.EDU
ReSent-Message-ID: <12445254976.19.TAJNAI@Score.Stanford.EDU>
TO COMPUTER SCIENCE PROFESSORS, RESEARCH ASSOCIATES AND PHD STUDENTS:
A reminder that the Sunrise Club will meet on Tuesday,
November 29 at 7:30 a.m. We meet at Tresidder Union,
Oak Lounge West. Professor Albert Macovski will speak
on "New Frontiers in Medical Imaging." Breakfast will
be served.
As always, we encourage CS graduate students to attend
Sunrise meetings.
Please respond to Bonnie Hiller (Hiller@score).
Thanks and hope to see you there.
Portia Leet
Events Coordinator
To: TAJNAI@SCORE
cc: NA.PHL
∂09-Nov-88 1325 @Score.Stanford.EDU:rokicki@polya.Stanford.EDU Programming Contest
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Nov 88 13:24:55 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 9 Nov 88 13:19:30-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA06521; Wed, 9 Nov 88 13:19:08 PDT
Date: Wed, 9 Nov 88 13:19:08 PDT
From: Tomas G. Rokicki <rokicki@polya.Stanford.EDU>
Message-Id: <8811092119.AA06521@polya.Stanford.EDU>
To: faculty@score
Subject: Programming Contest
Another ACM Programming Contest is nigh! Locals will be
held this Saturday in Turbo Pascal on IBM PCs. If any
faculty has an idea for a good problem, I would appreciate
having them sent to rokicki@polya. The problem can be a
puzzle or it can require an implementation of a basic
algorithm, such as longest monotonic sequence. Any
thoughts are greatly appreciated. -tom
∂09-Nov-88 1601 @Score.Stanford.EDU:winograd@loire.stanford.edu Re: PhD Program proposal
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Nov 88 16:00:50 PST
Received: from loire.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 9 Nov 88 15:58:17-PST
Received: by loire.stanford.edu (5.59/25-eef) id AA13213; Wed, 9 Nov 88 15:57:57 PDT
Date: Wed, 9 Nov 88 15:57:57 PDT
From: Terry Winograd <winograd@loire.stanford.edu>
Message-Id: <8811092357.AA13213@loire.stanford.edu>
To: GENESERETH@Score.stanford.edu, faculty@Score.stanford.edu
Subject: Re: PhD Program proposal
I basically agree with the proposal, but think that Arthur points to a real
problem and doesn't offer a realistic solution.
The issue is to get the advisors to take responsibility for their
students. In the past we have had trouble with some of them getting
them to a single yearly Black Friday meeting, even when one of their
students was in trouble (usually it is a student they would rather
forget!). Arthur suggests:
Each quarter, after a meeting between the student and his/her advisor
and/or reading committee, the advisor is to write a progress report letter
to the PhD committee.
A couple of years ago we felt it was bold to suggest that the committee meet
with the student at least once a year, and with no job other than to show up.
A genuine quarterly report is just unrealistic to ask for.
The question then is how to make sure that the advisor gets involved in
the early stages of problems. If we go to the quarterly subset
meetings, this will take some working out. Also, there is an
important factor in the social pressure that comes from having to
declare what you are going to do about a student in front of the rest
of the faculty at one of the review meetings. I am concerned that
without this, advisors will follow their natural tendencies to let
things slip and slide by until things finally reach the stage of final
review for dismissal.
--t
∂09-Nov-88 1814 misha@polya.Stanford.EDU Next aflb
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Nov 88 18:14:02 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA27164; Wed, 9 Nov 88 18:12:28 PDT
Date: Wed, 9 Nov 88 18:12:28 PDT
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8811100212.AA27164@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: Next aflb
is tomorrow, November 10, at 12:30 in room 352.
We will have a problem session.
There is no scheduled talk (everybody's busy
finishing STOC submissions).
Misha
∂09-Nov-88 1847 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: PhD Program proposal
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Nov 88 18:47:49 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 9 Nov 88 18:46:56-PST
Message-ID: <$uv3x@SAIL.Stanford.EDU>
Date: 09 Nov 88 1816 PST
From: Robert W Floyd <RWF@SAIL.Stanford.EDU>
Subject: re: PhD Program proposal
To: winograd@LOIRE.STANFORD.EDU,
GENESERETH@Score.Stanford.EDU, faculty@Score.Stanford.EDU
[In reply to message from winograd@loire.stanford.edu sent Wed, 9 Nov 88 15:57:57 PDT.]
Another approach, possibly compatible with previous suggestions:
divide ourselves into colleges, say three like those for the comp,
and do the Black Friday stuff independently. Deal with intercollegiate
students on an exception basis. Reduce by nearly a faactor of three
the number of students each of us must be concerned about.
(I told you guys years ago about the diseconomies of scale in
becoming a big department. Welcome to the megadepartment.)
∂10-Nov-88 0115 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu PhD Program?
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Nov 88 01:15:50 PST
Received: from Pescadero by SCORE.STANFORD.EDU with TCP; Thu 10 Nov 88 01:14:10-PST
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA02669; Thu, 10 Nov 88 01:16:09 PST
Date: Thu, 10 Nov 88 01:16:09 PST
From: "David Cheriton" <cheriton@pescadero.stanford.edu>
Message-Id: <8811100916.AA02669@Pescadero>
To: faculty@score.Stanford.EDU
Subject: PhD Program?
Reacting to the proposal:
1) I like the term "advisor". Note that it suggests that I am supposed to
advise, not babysit students. They are adults that should be able to
manage their lives, understand the requirements of the program, and
seek advice if they are having trouble. Too difficult at 22 years old?
2) Realistically, there is more return on making the good students better
than spending more time on students who (in my experience) primarily
lack the drive to be researchers.
3) What is the "resource" the the dept. is managing when we try to manage
the students more carefully? Presumably the student does not get
dept. support after the first year. If a faculty wants to support, why
not? Is it office space? If so, maybe it would be fruitful to target
specifically this problem. E.g. faculty are allocated a certain amount
of student space, adjusted by dept. chair, so advisor might terminate
( and would be motivated to) support and office space for non-performers.
In general, we are of course trying to produce "independent" reseachers.
Maybe, we should just give them until candidacy timeout to get their act
together (for those in ABD) and save our time and energy for those that do
seek our "advice".
David C.
∂10-Nov-88 0935 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Next Week's Faculty Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Nov 88 09:35:31 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 10 Nov 88 09:33:23-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA18793; Thu, 10 Nov 88 09:33:17 PDT
Date: Thu, 10 Nov 1988 9:33:13 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score
Subject: Next Week's Faculty Lunch
Message-Id: <CMM.0.87.595186393.chandler@polya.stanford.edu>
The weather has turned wet and cool ... winter is on its' way ... maybe it's
time to think about something different for our faculty lunches.
Instead of sandwiches, how does (1) beef or chicken enchalladas, etc. (2)
Acapulco chicken, etc. (3)Lasagne, etc or (4) Ravioli, etc. sound? We could
always get something vegie for our vegitarian contingent.
Please let me know if any of the above appeals to you, or give me any
suggestion you may have.
∂10-Nov-88 0936 emma@csli CSLI Calendar, November 10, 4:8
Received: from csli (CSLI.Stanford.EDU) by SAIL.Stanford.EDU with TCP; 10 Nov 88 09:36:03 PST
Received: by csli (4.0/4.7); Thu, 10 Nov 88 08:38:50 PST
Date: Thu, 10 Nov 88 08:38:50 PST
From: emma@csli (Emma Pease)
To: friends@csli
Subject: CSLI Calendar, November 10, 4:8
Sorry for the delay.
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
10 November 1988 Stanford Vol. 4, No. 8
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 10 November 1988
12 noon TINLecture
Cordura Hall Higher-Level Lexical Structure and Parsing
Conference Room Michael Tanenhaus
University of Rochester
(mtan@prodigal.psych.rochester.edu)
Abstract in last week's Calendar
2:15 p.m. CSLI Seminar
Cordura Hall Week 7: Premature Commitments in Language Resolution
Conference Room Michael Tanenhaus
University of Rochester
(mtan@prodigal.psych.rochester.edu)
3:45 p.m. Tea
Ventura Hall
____________
CSLI ACTIVITIES FOR NEXT THURSDAY, 17 November 1988
12 noon TINLunch
Cordura Hall Reading: "E-Type Pronouns in 1987"
Conference Room by Irene Heim
Discussion led by Fernando Pereira
(pereira@ai.sri.com)
Abstract below
2:15 p.m. CSLI Seminar
Cordura Hall Week 8: Some Aspects of the Connectionist
Conference Room Approach to Ambiguity Resolution
David Rumelhart
(der@psych.stanford.edu)
Abstract below
3:45 p.m. Tea
Ventura Hall
____________
NEXT WEEK'S TINLUNCH
Reading: "E-Type Pronouns in 1987"
by Irene Heim
Discussion led by Fernando Pereira
(pereira@ai.sri.com)
November 17
We will discuss Irene Heim's draft "E-Type pronouns in 1987." This
paper considers the question of whether there are good reasons to
prefer DRT or situation-theoretic treatments of bound anaphora to an
older approach, due to Evans, Cooper, and others, for which she coins
the term "E-type analysis." In an E-type analysis, a pronoun is
represented in LF as a term of the form f(v1,...,vn) where f is a
function made salient in the context and the vi are variables
associated to quantified expressions on which the pronoun depends.
Farmers, donkeys, paychecks, sage plants, spare pawns, and other
famous characters of semantics play excellent roles in a plot with
many unexpected turns.
____________
NEXT WEEK'S CSLI SEMINAR
The Resolution Problem for Natural-Language Processing
Weeks 8: Some Aspects of the Connectionist Approach
to Ambiguity Resolution
David Rumelhart
(der@psych.stanford.edu)
November 17
I will try to sketch the "connectionist program" for linguistic
information processing. In particular, I will challenge the idea of a
fixed lexicon and rather suggest how "word meanings" might be
"synthesized" as required by the contexts in which they occur. I will
offer slightly different instantiations of this idea---one of them
primarily due to Kowamoto and one due to McClelland and St. John. I
will also, time permitting, sketch the rather different connectionist
approach represented by the work of Gary Cottrel (among others).
____________
SYMBOLIC SYSTEMS FORUM
Logic and Information in Symbolic Systems
Jon Barwise and John Etchemendy
Friday, 11 November, 3:15
Sweet Hall, room 026 (basement)
Many cognitive scientists, though not all, take cognition to be
intrinsically symbolic. In particular, they view inference as symbol
manipulation. However, another view is that inference is the
extraction of information. How do these two views fit together?
The two of us are currently engaged in a project with SSP major
Alan Bush to build a computer system, Hyperproof, that allows the user
to reason by manipulating information, not symbols. The question is,
how can one get one's hands on information? To find out, come to our
talk.
Next week, 18 November, the Symbolic Systems Internship Forum will
be held: in it, each student and faculty sponsor will discuss how the
summer project went. This forum is open to the public and will be of
special interest to: (1) students interested in obtaining Symbolic
Systems Internships and (2) faculty interested in having interns.
∂10-Nov-88 1342 SLOAN@Score.Stanford.EDU Holidays
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Nov 88 13:42:28 PST
Date: Thu 10 Nov 88 13:40:06-PST
From: Yvette Sloan <SLOAN@Score.Stanford.EDU>
Subject: Holidays
To: Staff@Score.Stanford.EDU, Faculty@Score.Stanford.EDU
Message-ID: <12445523077.11.SLOAN@Score.Stanford.EDU>
This is a reminder about the University holidays for Thanksgiving, Christmas,
and New Year's.
Employees will have Thursday, November 24 and Friday, November 25 off for the
Thanksgiving holiday. The University holidays for Christmas fall on *Friday,
December 23* and Monday, December 26 **not** on Monday (26th) and Tuesday
(27th) as is indicated on the Stanford Academic Calendar. We will also be
enjoying the New Year's holiday on Monday, January 2, 1989.
Have a happy and safe holiday season.
--Yvette
-------
∂11-Nov-88 1022 aaai@sumex-aim.stanford.edu January Conference Call
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 11 Nov 88 10:22:07 PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA13196; Fri, 11 Nov 88 10:21:49 PST
Date: Fri, 11 Nov 1988 10:21:46 PST
From: AAAI <aaai@sumex-aim.stanford.edu>
To: officers:;@sumex-aim.stanford.edu
Cc: aaai@sumex-aim.stanford.edu
Subject: January Conference Call
Message-Id: <CMM.0.88.595275706.aaai@sumex-aim.stanford.edu>
I would like to notify everyone about the schedule for the next
Council conference call. We would like to hold it on Thursday,
January 12, at 4:00 pm EST. Please insert that date into your
calendar and I will be reminding you of the call during the
first week of January.
Cheers,
Claudia
∂11-Nov-88 1205 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu popl program
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Nov 88 12:05:07 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA20832; Fri, 11 Nov 88 12:04:44 PDT
Message-Id: <8811112004.AA20832@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 11 Nov 88 12:04:29 PST
Received: by BYUADMIN (Mailer R2.01) id 4120; Fri, 11 Nov 88 12:58:29 MST
Date: Fri, 11 Nov 88 11:26:20 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Ken Zadeck <fkz%CS.BROWN.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Ken Zadeck <fkz%CS.BROWN.EDU@Forsythe.Stanford.EDU>
Subject: popl program
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
--------------------
Program for Sixteenth Annual ACM SIGACT-SIGPLAN Symposium on
Principles of Programming Languages
Austin, Texas, January 11-13, 1989
Wednesday, January 11th
Tutorial: 8:30 - 9:30
The program dependence graph and its uses
Jeanne Ferrante (IBM T. J. Watson Research Center)
Session 1: 9:30 - 10:30
Chaired by Kenneth Zadeck
The program dependence graph and vectorization
William Baxter, Henry R. Bauer, III (University of Wyoming)
A rewriting semantics for program dependence graphs
Rebecca P. Selke (Rice University)
Session 2: 11:00 - 12:30
Chaired by Thomas Reps
An efficient method of computing static single assignment form
Ron Cytron, Jeanne Ferrante, Barry Rosen, Mark Wegman
(IBM T. J. Watson Research Center)
Kenneth Zadeck (Brown University)
Resolving circularity in attribute grammars with applications to
data flow analysis
S. Sagiv, N. Francez (Technion), O. Edelstein, M. Rodeh
(IBM Israel Scientific Center)
Fast interprocedural alias analysis
Keith D. Cooper, Ken Kennedy (Rice University)
Session 3: 2:00 - 4:00
Chaired by David MacQueen
How to make ad-hoc polymorphism less ad hoc
Philip Wadler, Stephen Blott (University of Glasgow)
Typechecking records and variants in a natural extension of ML
Didier Re'my (INRIA)
Extracting {F sub omega}'s programs from proofs in the
calculus of constructions
C. Paulin-Mohring (INRIA and LIENS)
Polymorphic unification and ML typing
Paris C. Kanellakis (Brown University),
John C. Mitchell (Stanford University)
Session 4: 4:30 - 6:00
Chaired by Joseph Goguen
Moded type systems for logic programming
Katherine A. Yelick (MIT Laboratory for Computer Science),
Joseph L. Zachary (University of Utah)
CLP* and constraint abstraction
Timothy J. Hickey (Brandeis University)
Fully abstract compositional semantics for logic programs
Haim Gaifman (Hebrew University), Ehud Shapiro (Weizmann Institute)
Thursday, January 12th
Tutorial: 8:30 - 9:30
Concurrent Processes
Samson Abramsky (Imperial College of Science and Technology)
Session 5: 9:30 - 10:30
Chaired by Moshe Vardi
A calculus of higher order communicating systems
Bent Thompsen (Imperial College)
A fully abstract trace model for dataflow networks
Bengt Jonsson (Swedish Institute of Computer Science)
Session 6: 11:00 - 12:30
Chaired by Gerard Berry
Efficient temporal reasoning
E. Allen Emerson, Tom Sadler,
Jai Srinivasan (University of Texas at Austin)
On the synthesis of a reactive module
Amir Pnueli, Roni Rosner (Weizmann Institute of Science)
Synthesis of concurrent systems with many similar sequential processes
Paul C. Attie, E. Allen Emerson (University of Texas at Austin)
Session 7: 2:00 - 4:00
Chaired by John Mitchell
The Modula-3 type system
Luca Cardelli, Greg Nelson, Bill Kalsow (DEC Systems Research Center)
Jim Donahue, Mick Jordan (Olivetti Research Center)
Dynamic typing in a statically-typed language
Martin Abadi, Luca Cardelli (DEC Systems Research Center)
Benjamin Pierce (Carnegie Mellon University)
Gordon Plotkin (University of Edinburgh)
Relating models of polymorphism
Jose' Meseguer (SRI International)
Generalized conjunctive types
Gennaro Monteleone (Carnegie Mellon University)
Session 8: 4:30 - 6:00
Chaired by Paul Hudak
Rewrite, rewrite, rewrite, rewrite, rewrite ...
Nachum Dershowitz, Ste'phane Kaplan (Hebrew University)
Partial order programming
D. Stott Parker (UCLA)
Temporal logic programming is complete and expressive
Marianne Baudinet (Stanford University)
Friday, January 13th
Session 9: 9:00 - 10:30
Chaired by Alan Demers
Realistic compilation by program transformation
Richard Kelsey, Paul Hudak (Yale University)
Continuation-passing, closure-passing style
Andrew Appel (Princeton University), Trevor Jim (AT&T Bell Laboratories)
Copy elimination in functional languages
K. Gopinath, John L. Hennessy (Stanford University)
Session 10: 11:00 - 12:30
Chaired by Butler Lampson
Incremental computation by function caching
William Pugh, Tim Teitelbaum (Cornell University)
Unified algebras and modules
Peter D. Mosses (Aarhus University)
Bisimulation through probabilistic testing
Kim G. Larsen, Arne Skou (Aalborg University)
∂11-Nov-88 1405 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Marist College -- Colloquium Series 88/89
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Nov 88 14:05:15 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA00580; Fri, 11 Nov 88 14:04:57 PDT
Message-Id: <8811112204.AA00580@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 11 Nov 88 14:04:42 PST
Received: by BYUADMIN (Mailer R2.01) id 6582; Fri, 11 Nov 88 15:03:42 MST
Date: Fri, 11 Nov 88 15:50:03 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"William J. Joel" <JZEM%MARIST.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "William J. Joel" <JZEM%MARIST.BITNET@forsythe.stanford.edu>
Subject: Marist College -- Colloquium Series 88/89
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
COLLOQUIUM SERIES 88-89
Division of Computer Science and Mathematics
Marist College
Poughkeepsie, NY
All talks are held in Lowell Thomas Communication Center Room
125. Refreshments will be served.
Date Thursday, November 17
Time. 11:25 - 12:45 am
Title. Bayesian Single-Stage Optimal Design
Speaker Abdul Sankoh, Marist College
Abstract This talk focuses on one of the problems in a Bayesian
finite population model when a Blackwell-Macqeen (1973)
process in relation to the finite population parameter
(X1,...,Xn). Specifically, a solution to the problem
of optimally allocating a stratified sample in a finite
population is presented.
Abdul Sankoh holds a B.S.Ed. (1981) from the Univer-
sity of Sierra Leone, an M.S. in Applied Math (1983)
from the University of Toledo, an M.A. in Statistics
(1986) from the State University of New York at Buffalo
and is a Ph.D. candidate in Statistics at SUNY/Buffalo.
He is writing his Ph.D. dissertation in the area of
finite population sampling from a Bayesian viewpoint.
He has taught both at SUNY/Buffalo and at the Universi-
ty of Toledo.
∂11-Nov-88 1644 GENESERETH@Score.Stanford.EDU New building
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Nov 88 16:44:00 PST
Date: Fri 11 Nov 88 16:42:28-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: New building
To: faculty@Score.Stanford.EDU
Message-ID: <12445818418.30.GENESERETH@Score.Stanford.EDU>
A few weeks ago, Ted Brown and associates presented their design for
the new cs buidling at a faculty lunch. At that time I thought the
design was brilliant in many respects, and I still do. However, I was
suspicious of the striking imbalance between the rectilinear left wing
(facing the building) and the curved right wing. Although I mentioned
it to Brown at the time, I didn't make a big fuss because, well,
sometimes I don't like a thing at first and then grow to like it
later. In this case, the opposite has happened. The more I have
thought about it, the more I have grown convinced it is a mistake. I
described the design to 8 outsiders (a mix of tech types and artsies),
and I was surprised that the response was unanimously negative (even
when I sounded positive). Am I alone in this opinion within the
department?
Now, I understand the arguments for the asymmetry. Looking
down Serra Street, the biology building gets in the way; and
so we don't want to show half a curve. However, that is NOT
an argument for puttinga curve on the other side.
Once you pass the biology building, you get struck in theface by this
highly imbalanced, disorienting structure. At that point , THERE
IS NO REASON WHY WHAT YOU SEE SHOULD NOT BE SYMMETRIC. Or at least
it should be balanced.
I also understand Brown's argument about wanting to provide a surprise
upon passing the biology building, gbut I don't particularly relish
a negative surprise. And it is my opinion that that is
what we are going to have.
Notice that I am NOT suggesting that the building need be symmetric,
only more balanced. I am NOT suggesting that we flush the entire
design. Quite the contrary. I love many aspects of it. The massing,
the inner courtyards, the tower, etc. I was also on the committee
that selected Brown as architect. I think he is a genius. But I DO
believe we should reconsider that curve. To please a few curve
lovers, we might visually upset most of the inhabitants of our campus.
At any rate,what I want to know is how you all feel about the
design. The impression had by the architect is that the faculty is
"highly pleased". I fo r one am not. How about you folks?
mrg
-------
∂11-Nov-88 1746 @Score.Stanford.EDU:jwilson@jaguar.Stanford.EDU New building
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Nov 88 17:46:34 PST
Received: from jaguar.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 11 Nov 88 17:45:25-PST
Received: by jaguar.Stanford.EDU (5.51/inc-1.01)
id AA03693; Fri, 11 Nov 88 17:49:02 PST
Date: Fri, 11 Nov 88 17:49:02 PST
From: James Wilson <jwilson@jaguar.Stanford.EDU>
Message-Id: <8811120149.AA03693@jaguar.Stanford.EDU>
To: GENESERETH@Score.Stanford.EDU
Cc: faculty@Score.Stanford.EDU
In-Reply-To: Mike Genesereth's message of Fri 11 Nov 88 16:42:28-PST <12445818418.30.GENESERETH@Score.Stanford.EDU>
Subject: New building
Mike,
I agree with you entirely. Do you want me to forward your message to
Ted Browm (brown@polya).
James
∂11-Nov-88 1827 @Score.Stanford.EDU:bhayes@polya.Stanford.EDU bboard posting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Nov 88 18:26:53 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 11 Nov 88 18:24:53-PST
Received: from LOCALHOST by polya.Stanford.EDU (5.59/25-eef) id AA18096; Fri, 11 Nov 88 17:56:18 PDT
Message-Id: <8811120156.AA18096@polya.Stanford.EDU>
To: faculty@score
Subject: bboard posting
Date: Fri, 11 Nov 88 17:56:15 -0800
From: bhayes@polya.Stanford.EDU
There are electronic bboards for discussions of both the new building
and the PhD program. While you may not read them yourself, many
students who are interested in these subjects do. If you send out a
message of general interest on either of these subjects please send a
copy to csd-building@polya or phd-program@polya.
-b
∂12-Nov-88 1420 @Score.Stanford.EDU:winograd@loire.stanford.edu Re: PhD Program?
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Nov 88 14:20:43 PST
Received: from loire.stanford.edu by SCORE.STANFORD.EDU with TCP; Sat 12 Nov 88 14:17:16-PST
Received: by loire.stanford.edu (5.59/25-eef) id AA00230; Sat, 12 Nov 88 14:19:09 PDT
Date: Sat, 12 Nov 88 14:19:09 PDT
From: Terry Winograd <winograd@loire.stanford.edu>
Message-Id: <8811122219.AA00230@loire.stanford.edu>
To: cheriton@pescadero.stanford.edu
Subject: Re: PhD Program?
Cc: faculty@score.Stanford.EDU
I object to the direction your last message suggests that we take with
respect to working with Ph.D students. People of all ages (2, 22 and
even 44 and 88) work better when they are treated with decent concern,
accepted not as robot idea-production machines but as human beings
(with all of the weakness and illogical foibles that implies), and seen
as part of a community, not as a resource to be exploited when useful
and dumped when they cause problems or waste your time.
You seem to equate productive intellectual ability with a kind of
hard-shelled individualism. In my experience that isn't a very a close
correlation. People (even brilliant ones) do find themselves with
problems, and they are least likely to "seek advice" when they view the
faculty as standing ready to label them as "non-performers" and
criticize them for not being sufficiently "independent researchers".
We are in a fortunate situation, in that the lure of Silicon Valley and
the presence of some big names in the field has been sufficient to make
our department attractive in spite of what is often seen as the
absence of a coherent educational program and a lack of concern for
students by the faculty. In the long run, this won't hold up. We
could find ourselves losing the ability to attract good students,
especially if we move in a direction that offers people an isolated and
hostile environment.
--t
∂12-Nov-88 1508 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu Re: PhD Program?
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Nov 88 15:07:57 PST
Received: from Pescadero by SCORE.STANFORD.EDU with TCP; Sat 12 Nov 88 15:04:24-PST
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA18130; Sat, 12 Nov 88 15:08:40 PST
Date: Sat, 12 Nov 88 15:08:40 PST
From: "David Cheriton" <cheriton@pescadero.stanford.edu>
Message-Id: <8811122308.AA18130@Pescadero>
To: winograd@loire.Stanford.EDU
Subject: Re: PhD Program?
Cc: faculty@score.Stanford.EDU
In-Reply-To: <8811122219.AA00230@loire.stanford.edu> from Terry Winograd
<winograd@loire> on Sat, 12 Nov 88 14:19:09 PDT
I think there is a real philosophical difference between Terry and I which
permeats our politics, our research, etc. However, I am disappointed in
the way he chose to state it.
In particular, I believe that my research group acts not just as a research
group but also as a social and support group. We organize lots of outings
and events, including an bi-weekly lunch, annual skating party, thanksgiving
dinner and various other random events (such as our whitewater rafting trip).
On the other hand, I have had visitors to the dept. say that they have been
astounded the degree that MJH appears like a deserted building except for
my area of the 4th floor. I believe that is an overstatement, but I do
believe that the students outside my group suffer alot more from isolation
and neglect than those within.
On the other hand, I'm here to do world-class research. I'm willing to
provide my students with a first-rate environment, financial support and
equipment and some amount of staff support. However, I expect them to work
hard and produce first rate work in this environment. I've helped lots of
students with minor crises but those who havent "found themselves yet" or
need to learn surfing, etc. first can go elsewhere.
Any student that is driven away by high expectations I'm glad to lose, and
the sooner the better.
The other aspect - I feel I am preparing students for the real world.
Anyone making hiring, publishing or funding decisions out there is going to
be a lot tougher than me, and they are getting tougher.
However, I would prefer this issue not detract from the main issue I raise
which is: Are we better off spending effort on the good students than trying
harder to police/mother the weaker performers?
∂13-Nov-88 1256 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu DEC's new MIPS-based workstation
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Nov 88 12:56:49 PST
Received: from Pescadero by SCORE.STANFORD.EDU with TCP; Sun 13 Nov 88 12:53:08-PST
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA24801; Sun, 13 Nov 88 12:54:01 PST
Date: Sun, 13 Nov 88 12:54:01 PST
From: "David Cheriton" <cheriton@Pescadero.stanford.edu>
Message-Id: <8811132054.AA24801@Pescadero>
To: faculty@score.Stanford.EDU
Subject: DEC's new MIPS-based workstation
A person from my group attended a non-disclosure announcement of this
new product (person was Ed Sznyter (ews@pescadero)) and wrote up a brief
summary of the relevant details. This is available from my secretary
if you are willing to abide by the NDA (isnt open-ness wonderful!)
So, please contact Nevena@pescadero if interested. Looks like a neat
machine!
DRC
∂14-Nov-88 0743 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Faculty Lunch - 11/15/88
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Nov 88 07:43:47 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 14 Nov 88 07:38:20-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA14452; Mon, 14 Nov 88 07:40:40 PDT
Date: Mon, 14 Nov 1988 7:40:38 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score
Subject: Faculty Lunch - 11/15/88
Message-Id: <CMM.0.87.595525238.chandler@polya.stanford.edu>
Just a reminder of tomorrow's faculty lunch...same time - 12:15, same place,
MJH-146. This week Gene Golub will describe progress and plans for the new
interdisciplinary program in Scientific Computing and Computational
Mathematics.
See you there....and HAPPY MONDAY!
∂14-Nov-88 0804 X3J13-mailer Re: Hawaii hotel reservations reminder
Received: from mitre.arpa by SAIL.Stanford.EDU with TCP; 14 Nov 88 08:03:52 PST
Full-Name: Jim Antonisse
Message-Id: <8811141546.AA14091@mitre.arpa>
Organization: The MITRE Corp., Washington, D.C.
To: Jan Zubkoff <jlz@lucid.com>
Cc: x3j13@sail.stanford.edu, jima@mitre.arpa
Subject: Re: Hawaii hotel reservations reminder
In-Reply-To: Your message of Wed, 02 Nov 88 09:25:32 -0800.
<8811021725.AA03055@challenger>
Date: Mon, 14 Nov 88 10:46:00 EST
From: jima@mitre.arpa
Jan,
What is the registration fee for Hawaii, and to whom should
I make out the check. (Apologies if you've sent this info out
before, I recently - rather rashly, I guess - flushed my mail
log.)
The agenda hasn't taken shape already, has it?
Jim A.
∂14-Nov-88 1030 @Score.Stanford.EDU:linton@interviews.stanford.edu Re: PhD Program?
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Nov 88 10:30:34 PST
Received: from interviews.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 14 Nov 88 10:26:11-PST
Received: by interviews.stanford.edu (5.57/Ultrix2.4-C)
id AA03983; Mon, 14 Nov 88 10:24:19 PST
Date: Mon, 14 Nov 88 10:24:19 PST
From: linton@interviews.stanford.edu (Mark Linton)
Message-Id: <8811141824.AA03983@interviews.stanford.edu>
To: cheriton@pescadero.stanford.edu, winograd@loire.stanford.edu
Subject: Re: PhD Program?
Cc: faculty@score.stanford.edu
I agree more with David C. than Terry, though I might state the approach
a little differently. Independent of the effect on the faculty,
I believe the students are better off if we expect a lot of them.
Hard-workers may become disillusioned if they see other students
kept on who are unproductive. My experience has been that students
are very aware of how productive their peers are or are not, and I have
had students tell me "it's about time" when I mention that I cut off support
to someone who has not been producing.
I think the "lack of concern" that Terry mentions is actually related
to being too nice. Concerned advisors talk with their students often and
evaluate their progress frequently. Concerned advisors are also interested
in making sure their students are happy with what they are doing because
unhappy students are usually unproductive.
We must accept that we will admit students who will not or should not
receive a Ph.D., and that caring for students as people includes
telling them when we know they are in trouble.
Mark
∂14-Nov-88 1104 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Final exams
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Nov 88 11:04:05 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 14 Nov 88 10:59:44-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA08841; Mon, 14 Nov 88 11:00:25 PDT
Date: Mon, 14 Nov 88 11:00:25 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8811141900.AA08841@Tenaya.stanford.edu>
To: STAGER@Score.Stanford.EDU
Cc: faculty@Score.Stanford.EDU, loomans@Score.Stanford.EDU,
stewart@Polya.Stanford.EDU, chou@Polya.Stanford.EDU,
tah@Polya.Stanford.EDU, plambeck@Polya.Stanford.EDU,
jk@Sail.Stanford.EDU, yao.pa@Xerox.COM, koch@Polya.Stanford.EDU,
stager@Score.Stanford.EDU
In-Reply-To: Claire Stager's message of Mon 7 Nov 88 14:37:20-PST <12444747062.23.STAGER@Score.Stanford.EDU>
Subject: Final exams
Claire (and the people cc'd on your note):
Your message about final exams reminds me of Tau Beta Pi teaching
evaluations. I hope everyone knows the process by which the
forms are handed out during the last class of the quarter. Time should
be made available for the students to complete the form. The Dean's
office attaches a great deal of importance to the Tau Beta Pi surveys
as one of the ways for us to evaluate teaching. -Nils
∂14-Nov-88 1130 X3J13-mailer Ignore that message
Received: from mitre.arpa by SAIL.Stanford.EDU with TCP; 14 Nov 88 11:30:41 PST
Full-Name: Jim Antonisse
Message-Id: <8811141928.AA16983@mitre.arpa>
Organization: The MITRE Corp., Washington, D.C.
To: x3j13@sail.stanford.edu
Subject: Ignore that message
Date: Mon, 14 Nov 88 14:28:40 EST
From: jima@mitre.arpa
Well, "repl" was a just a bit more zealous than I expected
it to be. Sorry to {x3j13 - Jan} for the dose of mistargeted
mail - Jim A.
∂14-Nov-88 1150 @Score.Stanford.EDU:jcm@ra.stanford.edu PhD Program? (philosophical discussion)
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Nov 88 11:50:20 PST
Received: from ra.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 14 Nov 88 11:45:34-PST
Received: by ra.stanford.edu (5.59/25-eef) id AA09094; Mon, 14 Nov 88 11:47:31 PDT
Date: Mon, 14 Nov 88 11:47:31 PDT
From: John Mitchell <jcm@ra.stanford.edu>
Message-Id: <8811141947.AA09094@ra.stanford.edu>
To: faculty@score.stanford.edu
Subject: PhD Program? (philosophical discussion)
In my limited experience as advisor of summer students
at Bell Labs, and thesis reader at various places, I have
found that what many students need is careful, honest
advice. Being "too nice," in the sense of letting someone
with a bad idea think he/she has a good one, is not helpful.
But often advisors go along with a bad idea, since it takes
time to evaluate a student's progress accurately.
I don't know what Linton meant by "too nice," but this seems
like a common pitfall to me.
Another phenomenon that many have undoubtably seen is the
student who sounds interested, learns all the buzz words,
talks a good story, and really does nothing. It takes
determination and hard work to do good research, and it only
makes sense to eventually loose patience with a student who
takes up your time and resources, without making a sincere effort
in return. Eventually, this kind of person should must be
encouraged to try some other line of work. This is a hard
decision to make, but I doubt anyone is helped by letting an
unproductive situation continue indefinitely.
∂14-Nov-88 1203 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: New building
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Nov 88 12:03:22 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 14 Nov 88 11:59:08-PST
Message-ID: <hAZRE@SAIL.Stanford.EDU>
Date: 14 Nov 88 1159 PST
From: Robert W Floyd <RWF@SAIL.Stanford.EDU>
Subject: re: New building
To: GENESERETH@SCORE.STANFORD.EDU, faculty@SCORE.STANFORD.EDU
[In reply to message from GENESERETH@Score.Stanford.EDU sent Fri 11 Nov 88 16:42:28-PST.]
I am also bothered by the building. It seems to me like
composing a sentence in halves, in two different languages,
and calling the result poetry. It seems to violate an
important esthetic convention. I also agree that there is
much in the building that I like.
∂15-Nov-88 0903 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Application of Splay Trees to Data Compression
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Nov 88 09:02:55 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA00724; Tue, 15 Nov 88 09:01:46 PDT
Message-Id: <8811151701.AA00724@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 15 Nov 88 09:00:49 PST
Received: by BYUADMIN (Mailer R2.01) id 8749; Tue, 15 Nov 88 10:00:36 MST
Date: Tue, 15 Nov 88 10:40:35 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Douglas Jones <jones%HERKY.CS.UIOWA.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Douglas Jones <jones%HERKY.CS.UIOWA.EDU@Forsythe.Stanford.EDU>
Subject: Application of Splay Trees to Data Compression
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
On Aug. 16 '88, I posted an offer of code for a UNIX utility that was based
on the data compression and encryption algorithms discussed in my Aug. '88
paper in Communications of the ACM. I have recently tried to compile this
code under the hc compiler on the IBM RT; this compiler is stricter than
most C compilers, and it detected a few errors (none of which have any
effect on the normal functioning of the code). Because of this, I am
offering a corrected version of the programs, free to anyone in a research
environment.
Note: To date, I have heard nothing about the security of this algorithm
when used for encryption. This remains an open question.
Douglas W. Jones
jones@herky.cs.uiowa.edu
∂15-Nov-88 1014 betsy@russell.Stanford.EDU meeting reminder
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Nov 88 10:14:45 PST
Received: by russell.Stanford.EDU (4.0/4.7); Tue, 15 Nov 88 10:16:50 PST
Date: Tue 15 Nov 88 10:16:50-PST
From: Betsy Macken <BETSY@CSLI.Stanford.EDU>
Subject: meeting reminder
To: faculty@russell.Stanford.EDU
Message-Id: <595621010.0.BETSY@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Don't forget the Stanford CSLI faculty meeting on Thursday, 17 November,
in the Cordura Conference Room at 4:00.
Betsy
-------
∂15-Nov-88 1033 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu New building
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Nov 88 10:33:45 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 15 Nov 88 10:29:34-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA00597; Tue, 15 Nov 88 10:31:29 PDT
Date: Tue, 15 Nov 88 10:31:29 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8811151831.AA00597@Tenaya.stanford.edu>
To: GENESERETH@Score.Stanford.EDU
Cc: faculty@Score.Stanford.EDU
In-Reply-To: Mike Genesereth's message of Fri 11 Nov 88 16:42:28-PST <12445818418.30.GENESERETH@Score.Stanford.EDU>
Subject: New building
I am glad to see discussion about the building design. Nothing has
been frozen yet; indeed several university committees still have to
approve. The questions that Mike Genesereth raises concern aesthetic
judgements about which people will differ. The design that Ted Brown
has presented has several enthusiastic admirers. My attitude toward
Mike's specific comments is "interesting; let's see what the reaction
is." So far, I conclude that there is no large movement among the
building's future inhabitants for drastic changes in the design.
-Nils
∂15-Nov-88 1059 @Score.Stanford.EDU:rse@sumex-aim.stanford.edu Re: New building
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Nov 88 10:58:57 PST
Received: from sumex-aim.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 15 Nov 88 10:54:30-PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA07351; Tue, 15 Nov 88 10:57:15 PST
Date: Tue, 15 Nov 1988 10:57:14 PST
From: Bob Engelmore <rse@sumex-aim.stanford.edu>
To: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Cc: GENESERETH@Score.Stanford.EDU, faculty@Score.Stanford.EDU
Subject: Re: New building
In-Reply-To: Your message of Tue, 15 Nov 88 10:31:29 PDT
Message-Id: <CMM.0.88.595623434.rse@sumex-aim.stanford.edu>
Nils,
I'm more concerned about the inside of the buildings than the outside. I
want to see comfortable and functional offices, sensible traffic patterns,
appropriate regard for our computing and communication needs, truly
controllable air conditioning (e.g. having windows that open, something
we lack at Welch Road), etc.
The exterior design seemed to me neither an obvious optimum nor an obvious
kludge. I doubt if we as a group will come to any consensus on a "better"
alternative.
I did have one concern, however. The concave exterior of Nox on its
south-facing side might act as a solar lens if the surface is reflective,
as I suspect it will be. With the winter sun shining on it at a low angle,
the light will be focused at the focal length of the lens. Has anyone
explored this? It would be pretty bad if some offices on the opposite side
(in Sox) were fried by this effect!
Bob
∂15-Nov-88 1326 GENESERETH@Score.Stanford.EDU Re: New building
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Nov 88 13:26:10 PST
Date: Tue 15 Nov 88 13:21:43-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: Re: New building
To: nilsson@Tenaya.Stanford.EDU
cc: faculty@Score.Stanford.EDU
In-Reply-To: <8811151831.AA00597@Tenaya.stanford.edu>
Message-ID: <12446830449.27.GENESERETH@Score.Stanford.EDU>
Nils,
The responses so far total 5 aginst the design, 1 for, and 2 indifferent.
mrg
-------
∂15-Nov-88 1529 LOGMTC-mailer Smuel Safra will speak at the next AFLB
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Nov 88 15:29:27 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA27483; Tue, 15 Nov 88 15:26:10 PDT
Date: Tue, 15 Nov 88 15:26:10 PDT
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8811152326.AA27483@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU, logmtc@sail
Subject: Smuel Safra will speak at the next AFLB
The next AFLB will be as usual this Thursday, Nov 17, at 12:30 in room
352. The speaker will be Shmuel Safra who will talk about his FOCS paper.
The following Thursday (Nov 24) is Thanksgiving and there will be no AFLB.
On The Complexity of $\omega$-Automata
Shmuel Safra
Weizmann Institute
Automata on infinite words were introduced by Buchi in order to give a
decision procedure for S1S, the monadic second-order theory of one
successor. Muller suggested deterministic $\omega$-automata as a means
of describing the behavior of non-stabilizing circuits. McNaughton
proved that the classes of languages accepted by nondeterministic
Buchi automata and by deterministic Muller automata are the same. His
construction and its proof are quite complicated, and the blow-up of
the construction is doubly exponential.
Our main result is a new determinization construction. The
advantages of the construction are that it is simpler and yields a
single exponent upper bound for the general case. This construction
is essentially optimal. Using the construction we can also obtain an
improved complementation construction for Buchi automata, which is
also optimal. Both constructions can be used to improve the complexity
of decision procedures that use automata-theoretic techniques.
∂15-Nov-88 1529 LOGMTC-mailer Smuel Safra will speak at the next AFLB
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Nov 88 15:29:27 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA27483; Tue, 15 Nov 88 15:26:10 PDT
Date: Tue, 15 Nov 88 15:26:10 PDT
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8811152326.AA27483@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU, logmtc@sail
Subject: Smuel Safra will speak at the next AFLB
The next AFLB will be as usual this Thursday, Nov 17, at 12:30 in room
352. The speaker will be Shmuel Safra who will talk about his FOCS paper.
The following Thursday (Nov 24) is Thanksgiving and there will be no AFLB.
On The Complexity of $\omega$-Automata
Shmuel Safra
Weizmann Institute
Automata on infinite words were introduced by Buchi in order to give a
decision procedure for S1S, the monadic second-order theory of one
successor. Muller suggested deterministic $\omega$-automata as a means
of describing the behavior of non-stabilizing circuits. McNaughton
proved that the classes of languages accepted by nondeterministic
Buchi automata and by deterministic Muller automata are the same. His
construction and its proof are quite complicated, and the blow-up of
the construction is doubly exponential.
Our main result is a new determinization construction. The
advantages of the construction are that it is simpler and yields a
single exponent upper bound for the general case. This construction
is essentially optimal. Using the construction we can also obtain an
improved complementation construction for Buchi automata, which is
also optimal. Both constructions can be used to improve the complexity
of decision procedures that use automata-theoretic techniques.
∂16-Nov-88 1028 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Visit of...
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Nov 88 10:28:34 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 16 Nov 88 10:22:43-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA11211; Wed, 16 Nov 88 10:01:12 PDT
Date: Wed, 16 Nov 1988 10:01:07 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: phd@score
Cc: chandler@polya.Stanford.EDU, nilsson@tenaya, faculty@score
Subject: Visit of...
Message-Id: <CMM.0.87.595706467.chandler@polya.stanford.edu>
Ryszard S. Michalski, PRC Professor of CS and Information Technology and
Professor Rine, both of George Mason University, will be visiting Stanford on
December 2. Professor Michalski has asked that I inform the CS PhD students
of their visit. They will be available to meet with students to inform you
of faculty positions at GMU and job opportunities in the Washington
metropolitan area. He will be using MJH-220 for these visits.
Please contact me if you would like to meet with Professors Michalski and
Rine.
Michalski sent literature you might be interested in looking over. Feel free
to stop by and take a look at it.
∂16-Nov-88 1238 barwise@russell.Stanford.EDU SSP grad fellowship
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Nov 88 12:38:14 PST
Received: from localhost by russell.Stanford.EDU (4.0/4.7); Wed, 16 Nov 88 12:39:19 PST
To: ssp-faculty@russell.Stanford.EDU
Subject: SSP grad fellowship
Date: Wed, 16 Nov 88 12:39:17 PST
From: Jon Barwise <barwise@russell.Stanford.EDU>
Dear Faculty,
Here is the state of things with respect to the graduate program,
followed by a request.
1) It has been approved.
2) Several of you have come forward with the idea that you have
grants which might well be used to support someone you were working with
in this program. This would usually be after the first couple of years
in the program.
3) Stanley has managed to get a one time award for the program from Ricoh of
$10,000, which is about 1/2 of a fellowhship. If we can parley this into
support from the dean, then we might be able to get Ricoh to make a more
continuing commitment.
4) CSLI might be able to provide some support for 3 and 4 year students in
the program that were not eligible for other sorts of grant support, at
least for the next 3 or 4 years.
What I have asked Dean Traugott to do is commit to one fellowship a
year for two years, with the expectation that the students will move
onto RA's after two years. If they didn't, then there would be no
fellowhip the third year.
BUT
Dean Traugott is basically asking the philosophy department to say that if
they were to go from having 4 fellowhships a year to 5, would they commit
have this program for their first commitment.
The philosophy department has been fighting for a long time to get
their allocation increased. I am not willing to ask them to make the
commitment the Dean is asking for. I want her to think of this as
a program like the History of Science program, which has its own
fellowship, which gets awarded thru History or Philosophy, depending
on where the student chooses to apply.
I would like your support. If you think the program is a good idea,
and deserves the universities support, please write or call Dean
Traugott and let her know how you feel. Her phone number is 3-3903.
Her address is Provost's Office, Building 10, SU, post code 2061. I
think she needs to know this matters to a number of faculty, not just
me, and that they come from a number of different departments.
Anything you have the time for will help.
Thanks,
Jon
∂16-Nov-88 1239 TAJNAI@Score.Stanford.EDU Resume Situation a Disaster!
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Nov 88 12:39:31 PST
Date: Wed 16 Nov 88 12:34:38-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Resume Situation a Disaster!
To: phd@Score.Stanford.EDU
cc: faculty@Score.Stanford.EDU, hiller@Score.Stanford.EDU
Message-ID: <12447084023.10.TAJNAI@Score.Stanford.EDU>
Forgive me for sending this message to all PHD students, but I don't have
time to make a distribution list -- there are approximately 55 PHD
students who were in the resume book last year,
are still active in the program (I believe),
and who have not updated their resumes.
If you do not want your resume included in the 1989 book (due to be
mailed on December 16), send me a message copying your advisor and
Prof. Nilsson, and tell me why you don't want to be included. Obviously,
if you have already accepted employment with another company, you don't
want to be included -- in that case we simply move your resume to archive.
The publisher's deadline is next week (yes, Thanksgiving), and we are running
out of time. We must have the resumes by Friday - Nov. 18. Bonnie Hiller
plans to work this weekend in order to meet the deadline.
We need you!
Students who need to update resumes:
Alur, Ash, Bronstein, Burns, Carpenter, Casley, Chambers, Christensen,
Crew, Davis, DeMichiel, Duran, Gangolli, Geddis, Guha, Healey, Howard,
Hung, Jones, Kaelbling, Kashtan, Kosoresow, Larrabee, Merchant,
Murdock, Nayak, Nowick, Phillips, Phipps, Plambeck, Ponceleon, Quass,
Radzik, Rathmann, Roach, Roy, Salesin, Sankar, Saraiya, Scales,
Schoen, Scholz, Shieber, Strat, Subi, Subramanian D., Subramanian A.,
Suhr, Traugott, Tuminaro, Unruh, Vavasis, Wilson, Wolverton, Zhu.
Bothner and Lowry are on the list, but I believe they have finished.??
Carolyn Tajnai
-------
∂16-Nov-88 1559 hoffman@csli.Stanford.EDU this weeks forum (nov. 18)
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Nov 88 15:59:19 PST
Received: by csli.Stanford.EDU (4.0/4.7); Wed, 16 Nov 88 15:51:04 PST
Date: Wed 16 Nov 88 15:51:03-PST
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: this weeks forum (nov. 18)
To: hoffman@csli.Stanford.EDU
Message-Id: <595727463.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
This week, the Symbolic Systems Forum will hold a discussion of this
summer's Symbolic Systems Internships. If you are a student or a faculty
interested in obtaining one for next summer, you should attend to get some
idea of how the internships were structured and what they accomplished.
-------
∂16-Nov-88 1606 barwise@russell.Stanford.EDU Traugott's email address
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Nov 88 16:06:24 PST
Received: from localhost by russell.Stanford.EDU (4.0/4.7); Wed, 16 Nov 88 16:07:39 PST
To: ssp-faculty@russell.Stanford.EDU
Subject: Traugott's email address
Date: Wed, 16 Nov 88 16:07:37 PST
From: Jon Barwise <barwise@russell.Stanford.EDU>
Yoav seems to have found Dean Traugott's email address, somehow:
cr.liz@forsythe
∂16-Nov-88 1759 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu POPL '89 Registration Information
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Nov 88 17:52:43 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA20935; Wed, 16 Nov 88 17:51:24 PDT
Message-Id: <8811170151.AA20935@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 16 Nov 88 17:50:29 PST
Received: by BYUADMIN (Mailer R2.01) id 8950; Wed, 16 Nov 88 18:47:49 MST
Date: Wed, 16 Nov 88 16:38:30 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
ND HECN E-mail Postmaster <INFO%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Resent-From: ND HECN E-mail Postmaster <INFO@NDSUVM1>
Comments: Originally-From: Bryan Fugate <fugate@mcc.com>
From: ND HECN E-mail Postmaster <INFO%NDSUVM1.BITNET@forsythe.stanford.edu>
Subject: POPL '89 Registration Information
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
This mail got transferred to me due to a local error. I am sorry about
the delay. Please note that the sender was THEORYNT@YKTVMX . Thanks.
----------------------------Original message----------------------------
------------------------------------
POPL '89 REGISTRATION INFORMATION
All applications for registration at the "early" rates must be
received by December 1, 1988. Notice of registration will be
mailed shortly after that date. Fill out the form below and
mail with a check to Barbara Ann Smith, MCC Software
Technology Program, P.O. Box 200195, Austin, TX 78720. Make
check payable in US dollars to POPL'89.
Registration packets will be available for pickup at the
Stouffer Hotel on Tuesday, January 10 from 6-10pm or from 8am
- 5pm on January 11, 1989.
For further information contact:
Bryan Fugate
(512) 338-3330,
email fugate@mcc.com
or Barbara Smith
(512) 338-3336
email basmith@mcc.com
POPL '89 REGISTRATION
Fee Schedule (Circle the appropriate entry below)
Category Early Late (after 12/1)
ACM & SIGACT/SIGPLAN Member $200 $250
ACM or SIGACT/SIGPLAN Member* $215 $275
Neither ACM nor SIG Member $250 $310
Full-time student $ 65 $ 85
*Those affiliated with SIG Institutional members also qualify
for SIG discount.
Registration includes 2 luncheons, banquet and proceedings.
Name ___________________________________
ACM/Student ID# ________________________
Title __________________________________
Company Name ___________________________
Address ________________________________
________________________________________
City ___________________________________
State _______________ Zip ______________
Country ________________________________
Phone __________________________________
E-mail _________________________________
Name to appear on badge ________________
________________________________________
Dietary restrictions ___________________
________________________________________
Fill out the above registration form and mail with a check to:
Barbara Ann Smith
MCC Software Technology Program
P.O. Box 200195
Austin, TX 78720
MAKE CHECK PAYABLE IN US DOLLARS TO POPL'89.
HOTEL INFORMATION
A block of rooms has been reserved for conference participants
at the Stouffer Hotel in Austin at special rates ($79 single,
$89 double). Deluxe rooms are available on the Club Floor ($99
single, $109 double). The Stouffer is located at 9721
Arboretum Blvd., Austin, Texas 78759. Call the Stouffer at
(512) 343-2626 or send the attached reservation form by
December 10th to get those rates. Reservations received after
December 10, 1988 will be accepted on a space-available basis.
The hotel will provide transportation from the airport to the
Stouffer. Call the above phone number when you arrive at the
Austin Airport for service.
HOTEL RESERVATION FORM
Association for Computing Machinery
POPL '89
January 10-13, 1989
Reservation cut-off date December 10, 1988
Please circle the preferred rate
Accommodations Single Double Triple Quad
# of people 1 2 3 4
Standard $79 $89 $99 $109
Deluxe (Club) $99 $109 N/A N/A
Name ________________________________
Sharing With ________________________
Company ____________________________
Address ____________________________
____________________________________
City _______________________________
State ______________ Zip ___________
Phone ______________________________
Additional Person(s) _______________
____________________________________
Signature __________________________
Please don't forget - the first night's room rental deposit must
accompany your request. Check or money order should be made
payable to the Stouffer Austin Hotel. Do not send currency.
CREDIT CARD GUARANTEE
Card Name _____________________________
Card Number ___________________________
Expiration Date _______________________
(Refundable if reservation is cancelled 24 hours prior
to arrival date)
Cardholder name ________________________
Arrival Date _____________ Arrival Time ___________
Dept. Date ______________ Dept. Time ______________
(Check in 3:00pm. Check-out 1:00pm)
Mail this form by Decemer 10, 1988 to:
The Stouffer Hotel
9721 Arboretum Blvd.
Austin, TX 78759
∂16-Nov-88 1759 emma@csli.Stanford.EDU CSLI Calendar, November 17, 4:9
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Nov 88 17:55:43 PST
Received: by csli.Stanford.EDU (4.0/4.7); Wed, 16 Nov 88 16:46:11 PST
Date: Wed, 16 Nov 88 16:46:11 PST
From: emma@csli.Stanford.EDU (Emma Pease)
To: friends@csli.Stanford.EDU
Subject: CSLI Calendar, November 17, 4:9
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
17 November 1988 Stanford Vol. 4, No. 9
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 17 November 1988
12 noon TINLunch
Cordura Hall Reading: "E-Type Pronouns in 1987"
Conference Room by Irene Heim
Discussion led by Fernando Pereira
(pereira@ai.sri.com)
Abstract in last week's Calendar
2:15 p.m. CSLI Seminar
Cordura Hall Week 8: Some Aspects of the Connectionist
Conference Room Approach to Ambiguity Resolution
David Rumelhart
(der@psych.stanford.edu)
Abstract in last week's Calendar
3:45 p.m. Tea
Ventura Hall
____________
CSLI ACTIVITIES FOR THURSDAY, 1 December 1988
2:15 p.m. CSLI Seminar
Cordura Hall Week 9: Interpretation as Abduction
Conference Room Jerry Hobbs
(hobbs@ai.sri.com)
Abstract below
3:45 p.m. Tea
Ventura Hall
4:00 p.m. STASS Seminar
Cordura Hall Multimodal, Information-based Inference
Conference Room Jon Barwise, Alan Bush, and John Etchemendy
(barwise@csli.stanford.edu, bush@csli.stanford.edu,
etch@csli.stanford.edu)
Abstract below
____________
ANNOUNCEMENT
Because of the Thanksgiving Holiday, there will be no Thursday events
and no Calendar on 24 November.
____________
NEXT CSLI SEMINAR
The Resolution Problem for Natural-Language Processing
Week 9: Interpretation as Abduction
Jerry Hobbs
(hobbs@ai.sri.com)
December 1
We will return to a discussion of knowledge-based AI approaches to the
resolution problem, and in particular to an approach using a scheme
for abductive inference developed in the TACITUS project at SRI. It
will be argued that to interpret a text, one must prove the logical
form of the text from what is already mutually known, merging
redundancies where possible and making assumptions where necessary.
It will be shown how the problems of, among others, reference,
ambiguity, and metonymy can be addressed with this method. This
approach, in addition, suggests an elegant and thorough integration of
syntax, semantics, and pragmatics---one moreover that works for
integration and generation both. This will be described, and its
significance for modularity will be discussed.
____________
STASS SEMINAR
Multimodal, Information-based Inference
Jon Barwise, Alan Bush, and John Etchemendy
(barwise@csli.stanford.edu,
bush@csli.stanford.edu, etch@csli.stanford.edu)
Cordura Conference Room
December 1, 4:00-5:30
We will talk about our work designing an inference system that allows
the direct manipulation of information provided via different
modalities (e.g., visual and sentential). We will demonstrate a
mock-up of a program we are developing to teach this approach to
inference.
Time and place subject to change due to the availablity of equipment.
____________
PHILOSOPHY DEPARTMENT TALK
"Unless"---Norms and Default Reasoning
Professor Irina Gerasimov
Institute of Philosophy
Soviet Academy of Sciences, Moscow
Thursday, 17 November, 4:15 p.m.
Ventura Seminar Room
____________
SYMBOLIC SYSTEMS FORUM
Symbolic Systems Internship Forum
Friday, 18 November, 3:15
Bldg. 60:62N
In the Symbolic Systems Internship Forum, each student and faculty
sponsor will discuss how the summer project went. This forum is open
to the public and will be of special interest to: (1) students
interested in obtaining Symbolic Systems Internships and (2) faculty
interested in having interns.
____________
CSLI TALK
External and Internal Logics
Professor Vladimir Smirnov
Institute of Philosophy
Soviet Academy of Sciences, Moscow
Sponsored by
Department of Philosophy, CSLI, and IMSSS
Tuesday, 22 November, 4:15 p.m.
Ventura Seminar Room
Tea will be held at 3:45 in the Ventura Lounge
____________
ANNOUNCEMENT
The Stanford Department of Philosophy announces a new special program
within their Ph.D. program: Philosophy and Symbolic Systems. The
program is designed to allow students to do interdisciplinary
coursework and research in the area of symbolic systems. For more
information, contact the philosophy department (723-2547) or Jon
Barwise (barwise@csli.stanford.edu).
∂17-Nov-88 1549 TAJNAI@Score.Stanford.EDU Speakers for 1989 Forum Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Nov 88 15:48:55 PST
Date: Thu 17 Nov 88 15:42:55-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Speakers for 1989 Forum Meeting
To: PHD@Score.Stanford.EDU, faculty@Score.Stanford.EDU,
csl-students@Sierra.Stanford.EDU
Message-ID: <12447380441.28.TAJNAI@Score.Stanford.EDU>
It would be helpful if you would let me know if you plan to send an
abstract for a talk to be presented at the annual meeting in February
(Feb. 15/16).
There has been concern voiced by some of the students that they will not
be given a slot on the program. We definitely want to include all students
who expect to graduate before February 1990.
In the last few meetings we have included students who still had 2 or
sometimes 3 years to go before receiving the PHD. We want each student to
speak at a Forum program before graduation, but prefer that it be his/her
last year.
I have received one abstract (nice and early) and a few names, but not
enough information yet to know where we stand. Just a message now
indicating that you want to speak (students and faculty) and a subject area.
Thanks,
Carolyn Tajnai, Director Computer Forum
-------
∂17-Nov-88 1724 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Nov 88 17:24:10 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 17 Nov 88 17:20:09-PST
Message-ID: <hCuA7@SAIL.Stanford.EDU>
Date: 17 Nov 88 1722 PST
From: Robert W Floyd <RWF@SAIL.Stanford.EDU>
To: faculty@Score.Stanford.EDU
The following quotation comes from "A Case of Academic Freedom"
by Joseph Epstein in Commentary a few years ago. I agree with it,
and I think we eglect our responsibilities if we regard student evaluations
of teaching as anything more than fire alarms. Particularly
because I have yet to meet a student who knew that promotion
and salary decisions are heavily based on the raw averages
and percentiles.
...at least at large universities mindful of their
prestige...a college teacher's classroom has become his castle,
and he is free to do there as he pleases. Colleagues do not make
judgments about a fellow teacher's teaching. Instead, under the new
dispensation, students do. Students always have done so, of course,
but whereas earlier they did so informally, now, through something called
evaluation forms, they do so formally. On the final days of a class,
with perhaps ten or twenty minutes remaining, a professor passes out
evaluation forms on which students remark on the strengths and
deficiencies of his course. In cases where a professor is coming up
for tenure, these evaluations are considered by his colleagues with some
care. Tenured faculty, in these instances, do not directly judge the
teacher; they judge the students' judgments, which is not quite the same thing.
Not that judging teaching is easy. As everyone who has been to college
knows, a dull teacher can sometimes leave a lasting impress. What seems exciting
in one's youth, ten years later seems facile, if not silly. Teaching,
especially teaching the large, so-called soft subjects in the humanities,
where mastery of specific problems is not the chief business at hand, but
asking the right questions is, is a subtle art. Student evaluations of
one's own teaching do not help. These evaluations can capture real
delinquency, citing a professor's many absences or his obvious unpreparedness.
But beyond that, in the realm where useful distinctions might be made, they
leave everything to be desired. Evaluations of my own teaching tend to be
quite positive, and my teaching is almost always held to be--most ambiguous
of words--``interesting.''. But how much gets through, how long it will
remain, I haven't the least idea, and my guess is that neither does any
other teacher. The most touching student evaluation I have ever received
noted: ``I did well in his course because I would have been ashamed not to
do well for him.'' But of the content of what I teach, and of the quality of
thought that goes into this content--nothing. Undergraduate students can
hardly be expected to be fit to judge this, and by and large they do not.
∂17-Nov-88 1926 SHOHAM@Score.Stanford.EDU department colloquium
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Nov 88 19:26:52 PST
Date: Thu 17 Nov 88 19:16:12-PST
From: Yoav Shoham <SHOHAM@Score.Stanford.EDU>
Subject: department colloquium
To: faculty@Score.Stanford.EDU
Message-ID: <12447419269.9.SHOHAM@Score.Stanford.EDU>
We're hoping to get truly high-caliber speakers. It has been pointed
out that one way to get Famous People to visit us is to get local
Famous People invite their friends. Please let Jeff Eppinger or me
know if you have suggestions. We need to act fast, to get people to
commit already to the Winter quarter.
Yoav
-------
∂17-Nov-88 2247 tah@linz MTC Seminar
Received: from linz.stanford.edu by SAIL.Stanford.EDU with TCP; 17 Nov 88 22:47:13 PST
Received: by linz.stanford.edu (5.59/25-eef) id AA11149; Thu, 17 Nov 88 22:45:21 PDT
Message-Id: <8811180645.AA11149@linz.stanford.edu>
To: alur@polya, arean@polya, barwise@russell, bhoward@polya, chavez@sumex-aim,
clt@sail, coraki!pratt@sun.com, crew@polya, devlin@csli, dill@amadeus,
eswolf@polya, fernando@csli, galbiati@polya, grove@polya,
gurevich@polya, herskovits@sumex-aim, hirani@sun.com, howard@polya,
jcm@ra, jmc-lists@sail, kar@polya, kolaitis@polya, lincoln@polya,
lowry@coyote, ma@src.dec.com, martin@polya, mb@jeeves, mcguire@polya,
shankar@score, olthoff@hplabs.hp.com, peters@russell, pieper@geode,
polaschek@sumex-aim, rdz@score, rjw@sail, roach@score, rtc@sail,
sf@csli, traugott@polya, val@sail, vardi@polya, vasilis@polya,
weening@gang-of-four, zm@sail, tah@linz, nowick@polya, alex@jessica,
katiyar@polya
Subject: MTC Seminar
Date: 17 Nov 88 22:45:17 PST (Thu)
From: Tom Henzinger <tah@linz>
Stirred up by the recent flurry of messages on Albert Meyers types
mailing list, we've decided to sort out everything about initial,
final, and penultimate (ask Vaughan about those) algebras tomorrow
(Friday noon, MJH 301).
I think John's question that started everything was: What should
be considered to be a correct implementation of an algebraic
specification? (Ehrig/Mahr suggest implementations ought to be
isomorphic to the initial algebra; John wants something less
restrictive, like observational equivalence, or a logical relation,
with the initial algebra, which would actually be closer to the
final-algebra approach to algebraic semantics (how?).)
Another topic the will be brought up (next meeting?) are algebras
of partial functions.
-- Tom.
∂18-Nov-88 0108 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU re: New building
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Nov 88 01:08:52 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 18 Nov 88 01:05:16-PST
Message-ID: <LCE3w@SAIL.Stanford.EDU>
Date: 17 Nov 88 2357 PST
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: re: New building
To: GENESERETH@SCORE.STANFORD.EDU, faculty@SCORE.STANFORD.EDU
[In reply to message from GENESERETH@Score.Stanford.EDU sent Fri 11 Nov 88 16:42:28-PST.]
Mike's message has stimulated me to make my own comment. I think we
should know how much larger a building we could have for the same
cost if the eternal glory of the architect were not a consideration.
I'll bet the biologists are getting a lot more square feet per dollar.
Maybe once the facts are known, the faculty will like the present plan.
Remember it's the last $50 million we'll get in some time, and our
activities tend to grow.
∂18-Nov-88 0951 @Score.Stanford.EDU:winograd@loire.stanford.edu Student evaluations
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Nov 88 09:51:24 PST
Received: from loire.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 18 Nov 88 09:47:21-PST
Received: by loire.stanford.edu (5.59/25-eef) id AA10892; Fri, 18 Nov 88 09:49:20 PDT
Date: Fri, 18 Nov 88 09:49:20 PDT
From: Terry Winograd <winograd@loire.stanford.edu>
Message-Id: <8811181749.AA10892@loire.stanford.edu>
To: RWF@SAIL.Stanford.EDU
Subject: Student evaluations
Cc: faculty@Score
I am sympathetic with the point that you make, but am not sure how it should
apply to us. First of all, the vast majority of our courses and students
are graduate, not undergraduate. Although much of what Epstein says applies
to all evaluations, we need to recognize that our graduate students are on
the verge of being professionals themselves, and do have a good deal of
knowledge and maturity.
The second issue, even with undergraduate courses, is how we are to evaluate
teaching. Evaluations outside of the teacher's own self-observations
are needed for a variety of reasons, including the obvious ones of
salary and promotion, but also indirect ones like knowing what to adivse
our students to take, and designing the overall curriculum. Undergraduates
may not be the best judges (though also not necessarily the worst), but
what alternatives do you suggest? Should we set up an evaluation committee
and have them do formal reviews? Should we hire "professional educational
evaluators"? Are we ready to spend time going to each others' classes and
then be direct about our real opinions? In the absence of alternatives
we need to do the best we can to promote quality in the student reviews,
and then take them seriously, not as gospel but also as more then
"fire alarms." They contain valuable information, when it is
interpreted in the context of the remarks you quote.
--t
∂18-Nov-88 1054 @Score.Stanford.EDU:binford@Boa-Constrictor.Stanford.EDU New building
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Nov 88 10:54:23 PST
Received: from Boa-Constrictor.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 18 Nov 88 10:50:32-PST
Received: by Boa-Constrictor.Stanford.EDU.stanford.edu (4.0/SMI-DDN)
id AA00156; Fri, 18 Nov 88 10:45:43 PST
Date: Fri, 18 Nov 88 10:45:43 PST
From: binford@Boa-Constrictor.stanford.edu (Tom Binford)
Message-Id: <8811181845.AA00156@Boa-Constrictor.Stanford.EDU.stanford.edu>
To: nilsson@tenaya.stanford.edu
Cc: GENESERETH@score.stanford.edu, faculty@score.stanford.edu
Subject: New building
I was not enthusiastic about the building. My sense of the
design was that it was somewhat chaotic.
∂18-Nov-88 1106 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: New building
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Nov 88 11:06:16 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 18 Nov 88 11:00:16-PST
Message-ID: <$CYyq@SAIL.Stanford.EDU>
Date: 18 Nov 88 1102 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: New building
To: faculty@SCORE.STANFORD.EDU
It is clear to me that the increase in perimeter will greatly increase
the cost per net square foot. This increase is primarily due to the
demand of everyone for a window. (Hopefully, we can have windows *and*
air conditioning, unlike in MJH.) However, as the cost per net square foot
goes up, either the total cost goes up or the size goes down. The
problems either of these cause lead to hardship in either case. In the
case of MJH, it led to inclusion of "Boys Town" (that's what they were
called then) because of largess of Father Flanigan's money amassing
operation paid for part of the capital costs of the building.
I'm a pragmatist. The cost containment issue will affect us in more
profound ways than esthetics ever could.
Arthur
∂18-Nov-88 1200 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: New building
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Nov 88 12:00:22 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 18 Nov 88 11:55:10-PST
Message-ID: <hCZPW@SAIL.Stanford.EDU>
Date: 18 Nov 88 1157 PST
From: Robert W Floyd <RWF@SAIL.Stanford.EDU>
Subject: re: New building
To: faculty@SCORE.Stanford.EDU
[In reply to message sent 17 Nov 88 2357 PST.]
John's message suggested a design to me:
*
***
*****
*******
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* CSD *
* ***** *
* * * *
* * * *
* * * *
*********************************************************************************
/ \
/ WELCOME \
/_______________\
However, as it is somewhat visionary, I am not sure we would be
able to get the bureaucrats to approve.
∂18-Nov-88 1432 @Score.Stanford.EDU:%orc.olivetti.com@NET.BIO.NET Re: Speakers for 1989 Forum Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Nov 88 14:32:46 PST
Received: from net.bio.net by SCORE.STANFORD.EDU with TCP; Fri 18 Nov 88 14:23:46-PST
Received: from orc.olivetti.com by net.bio.net (5.59/1.15) with UUCP
id AA27698; Fri, 18 Nov 88 14:15:29 PST
Received: from ivrea.orc.olivetti.com by orc.olivetti.com (3.2/SMI-3.2)
id AA05593; Fri, 18 Nov 88 14:03:32 PST
Received: by ivrea.orc.olivetti.com (3.2/SMI-3.2)
id AA02412; Fri, 18 Nov 88 14:15:33 PST
From: lauwers@orc.olivetti.com (Chris Lauwers)
Message-Id: <8811182215.AA02412@ivrea.orc.olivetti.com>
To: Carolyn Tajnai <TAJNAI@score.stanford.edu>
Cc: PHD@score.stanford.edu, faculty@score.stanford.edu,
csl-students@sierra.stanford.edu, ivrea!lauwers@NET.BIO.NET
Subject: Re: Speakers for 1989 Forum Meeting
In-Reply-To: Your message of Thu, 17 Nov 88 15:42:55 -0800.
<12447380441.28.TAJNAI@Score.Stanford.EDU>
Date: Fri, 18 Nov 88 14:15:32 -0800
Carolyn,
I would like to give a talk at the forum meeting. I don't have an
abstract yet, but will send one to you sometime next week. Here is
some information:
Name: J. Chris Lauwers
Faculty Advisor: Keith A. Lantz
Research Area: user interfaces for distributed systems
Title of Talk: Software Infrastructure for Real-time collaboration
Date of expected graduation: fall 1989
Abstract: will follow
Chris
∂18-Nov-88 1620 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: Student evaluations
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Nov 88 16:19:59 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 18 Nov 88 16:15:36-PST
Message-ID: <1rCzDY@SAIL.Stanford.EDU>
Date: 18 Nov 88 1617 PST
From: Robert W Floyd <RWF@SAIL.Stanford.EDU>
Subject: re: Student evaluations
To: winograd@LOIRE.STANFORD.EDU, RWF@SAIL.Stanford.EDU
CC: faculty@SCORE.Stanford.EDU
[In reply to message from winograd@loire.stanford.edu sent Fri, 18 Nov 88 09:49:20 PDT.]
Sorry the following is so long; I didn't have time to write a short memo.
Terry's questions are some of the right ones to ask in a discussion
about course evaluation. Here are some of my thoughts on them.
Our PhD students are indeed on the margin of being younger
colleagues. They also feel little need for filling out an
anonymous form; they will tell a professor directly what they
like and dislike. They are not required to take any course,
so they take courses in which they are self-motivated. In
PhD level courses, evaluations are probably largely based
on content, and evaluations of content are probably fairly
good. Even our MS students, though, are a very different
population. They take many courses they are forced to take,
and their overall motivations are mixed. When I update
traditional material, I have little evidence that they are
aware of the differences. Between undergrad courses and
MS courses, I think Epstein's views apply to a majority
of the courses (or at least the units) we teach.
Who should evaluate? Some suggestions come to mind. We
could reasonably ask undergrads a year later whether a
course prepared them for subsequent work. Ask in 107
or 108B about cs106. We have a visiting committee for
the department, and research grants have site visits:
we could institute something like that, probably on a
basis of evaluation every three years or so. When I was
chairman, I observed myself any courses that showed signs
of problems, and took actions ranging from cancelling a
follow-on course by a visitor who was completely out of
touch to giving friendly advice to a very nervous lecturer
whose students would have better advised to try to make
him comfortable so that they could learn the good stuff
he knew, than to heckle him as some did. A chairman or
his delegate can watch most professors on TV unobtrusively.
A rresearch-level course probably can be evaluated for
content by the process of evaluating the professor's
research. I think we might well drop most formal
evaluation of such courses in favor of optional
advisory questionnaires.
An upper level core course might be evaluated by
colleagues within a specialty at specified intervals.
This evaluation would aim at the curriculum objectives
of maintaining currency and reducing unwanted overlap.
In the process, faults like lack of preparation would
be apparent. A mandatory letter from the evaluators
to the lecturer would be taken seriously at least by
those bucking for tenure. For established tenured
professors, it is often politically impossible to
penalize utterly sloppy teaching currently, and it
might get no better.
Entry level courses are a hard problem. I myself
favor continual oversight and responsibility by
academic council members, with regular reports to
the chairman or his professorial delegates, for
courses taught by students or ephemeral lecturers.
Evaluation by the students themselves is hard to
take seriously. Observations include:
* Most evaluation forms give a course the same rank
on every question asked.
* Comments on evaluation forms may be a condemnation
of the course for not teaching flowcharting (discredited
by research) or for teaching "the philosophy of
programming" rather than all the details of a
programming language.
* Someone who taught a
section of my intro course out of my notes, using
my organization and assignments, got much
better evaluations.
* Students dump all problems of a course onto the
evaluations. Comp center failure, insufficient
or incompetent TAs, are among the reasons for
catastrophic evaluation. It's like the navy; if
it happens on your watch, you're responsible. But
the navy is designed to expect hostile activity.
* I taught two sections of the same course, differing
only in the TA. One TA was green but smart and likeable,
the other dim and arrogant. One course got creditable
evaluations, the other helped persuade influential
persons that I was a bad teacher. (Recent evaluations
on request.)
Whatever the solutions, we should begin by acknowledging
a problem. The existing system has never to my knowledge
been validated in any way. Designed to advise students
about what courses other students think they shouuld take,
it is used to make salary and promotion decisions. The
existing system makes this department look relatively bad,
or at least it did two years ago when we were near the bottom
of the engineering division. Either it was an invalid
system, or we were failing as teachers. Either way, we
have a problem. We should ask ourselves what we want to
measure, and whether to do so objectively or subjectively.
Then we should confirm that we do measure what we are trying to.
∂19-Nov-88 0903 LOGMTC-mailer Albert Meyer's TYPES mailing list
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Nov 88 09:03:41 PST
Received: from LOCALHOST by polya.Stanford.EDU (5.59/25-eef) id AA28469; Sat, 19 Nov 88 09:03:41 PDT
Message-Id: <8811191703.AA28469@polya.Stanford.EDU>
To: logmtc@sail.stanford.edu
Subject: Albert Meyer's TYPES mailing list
Reply-To: types-request@polya.stanford.edu
Date: Sat, 19 Nov 88 09:03:40 -0800
From: Roger Crew <crew@polya.Stanford.EDU>
Anyone wishing to be on Albert Meyer's TYPES mailing list
should be aware that I've set up a local redistribution.
Requests for additions/deletions/changes in this local
list should go to me at
types-request@polya.stanford.edu
Those of you who are already on the MIT list don't need to do
anything. You will continue to get TYPES from MIT unless you've
gotten a message from me saying otherwise.
Roger
∂19-Nov-88 1330 @Score.Stanford.EDU:gio@sumex-aim.stanford.edu Re: New building
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Nov 88 13:30:18 PST
Received: from sumex-aim.stanford.edu by SCORE.STANFORD.EDU with TCP; Sat 19 Nov 88 13:26:34-PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA01544; Sat, 19 Nov 88 13:29:34 PST
Date: Sat, 19 Nov 1988 13:29:33 PST
From: Gio Wiederhold <gio@sumex-aim.stanford.edu>
To: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Cc: nilsson@Tenaya.Stanford.EDU, faculty@Score.Stanford.EDU
Subject: Re: New building
In-Reply-To: Your message of Tue 15 Nov 88 13:21:43-PST
Message-Id: <CMM.0.88.595978173.gio@sumex-aim.stanford.edu>
If we're voting -- I am against the asymmetry of the latest plans.
However, neither art nor science is best managed by democratic processes.
Gio
∂19-Nov-88 1819 LOGMTC-mailer Smuel Safra will speak at the next AFLB
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Nov 88 18:19:23 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA27483; Tue, 15 Nov 88 15:26:10 PDT
Date: Tue, 15 Nov 88 15:26:10 PDT
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8811152326.AA27483@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU, logmtc@sail
Subject: Smuel Safra will speak at the next AFLB
The next AFLB will be as usual this Thursday, Nov 17, at 12:30 in room
352. The speaker will be Shmuel Safra who will talk about his FOCS paper.
The following Thursday (Nov 24) is Thanksgiving and there will be no AFLB.
On The Complexity of $\omega$-Automata
Shmuel Safra
Weizmann Institute
Automata on infinite words were introduced by Buchi in order to give a
decision procedure for S1S, the monadic second-order theory of one
successor. Muller suggested deterministic $\omega$-automata as a means
of describing the behavior of non-stabilizing circuits. McNaughton
proved that the classes of languages accepted by nondeterministic
Buchi automata and by deterministic Muller automata are the same. His
construction and its proof are quite complicated, and the blow-up of
the construction is doubly exponential.
Our main result is a new determinization construction. The
advantages of the construction are that it is simpler and yields a
single exponent upper bound for the general case. This construction
is essentially optimal. Using the construction we can also obtain an
improved complementation construction for Buchi automata, which is
also optimal. Both constructions can be used to improve the complexity
of decision procedures that use automata-theoretic techniques.
∂20-Nov-88 0359 X3J13-mailer Phase 1 standard
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Nov 88 03:59:10 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA25899; Sun, 20 Nov 88 03:58:33 PST
Message-Id: <8811201158.AA25899@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 20 Nov 88 06:49
To: x3j13@sail.stanford.edu
Subject: Phase 1 standard
The source files for the phase 1 standard (complete as far as we know now)
are located on hudson.dec.com. The account name is FTP_USER and the password
is FTPPLEASEWORK.
Please let me know your specific needs if you intend to review this document.
The .dvi files will be available by Dec. 2. If you intend to use those, the
file names are chapter1.dvi...chapter6.dvi, and chapter6-1.dvi. The chapter 6
files are quite large.
If you want to build the document from the source files, you will need
TEX and TEX amfonts on your machine. To build the document, you invoke
TEX 7 times, each time with the file name chapterx, where
x=1,2,3,4,5,6,6-1.
Please let me know if you have any problems.
kathy chapman
∂20-Nov-88 1047 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Tues Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Nov 88 10:47:18 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sun 20 Nov 88 10:43:12-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA03941; Sun, 20 Nov 88 10:44:47 PDT
Date: Sun, 20 Nov 88 10:44:47 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8811201844.AA03941@Tenaya.stanford.edu>
To: faculty@score
Subject: Tues Lunch
This Tuesday, Nov 22, John Mitchell will be leading a discussion at
our faculty lunch on topics important to our junior faculty. Since
many of these topics concern relations between junior faculty and some
of us older types, I sincerely hope the lunch will be well attended.
I consider our junior faculty to be the Department's most important
asset. They are our future. Let's all do our best next Tuesday to
hear what the future is saying.
-Nils
∂20-Nov-88 1505 hoffman@csli.Stanford.EDU about the Symbolic Systems Program
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Nov 88 15:04:56 PST
Received: by csli.Stanford.EDU (4.0/4.7); Sun, 20 Nov 88 15:03:17 PST
Date: Sun 20 Nov 88 15:03:15-PST
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: about the Symbolic Systems Program
To: ssp-faculty@csli.Stanford.EDU
Message-Id: <596070195.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Dear Faculty,
In this letter, I will illustrate a serious problem with the educational side
of Symbolic Systems and then suggest a solution.
Admittedly, Symbolic Systems suffers from the problem which bedevils all
interdisciplinary majors: no control over its own classes and thus troubles
with delivering a coherent education. However, I believe that most
interdisciplinary majors have one of three saving graces: (1) a very clearly
defined (and agreed upon) subject matter, (2) being closely wedded to a
particular department, or (3) having some of its own classes to teach its own
methodology. Symbolic Systems, unfortunately, does not have any of these.
Indeed, I think that most (all?) undergraduates study each of the disciplines
in a patchwork fashion: they study each discipline or class by itself without
the ability (or perhaps in some cases inclination) to build what they learn
into a larger framework. The best image which comes to mind is the
stereotypical engineer who takes all the classes which he or she "has to" and
never builds that into some coherent intellectual picture. Thus, a Symbolic
Systems student ends up getting a potpourri of different classes which
frequently overlap in various simple ways (i.e. I have learned proposition
logic about 4 times and will likely relearn it some time soon) and very often
resist any sort of reasoning across disciplines (and thus learning a coherent
Symbolic Systems methodology.)
Actually, most students in any discipline would have trouble with
developing a coherent picture out of a series of haphazard classes. Most
traditional disciplines beat this problem by offering core classes which
systematically teach its basic tools and then more advanced courses which
develop the sophistication of those tools and test them on various subject
matter. Symbolic Systems cannot pursue this solution as it has no control
over the course material.
However, as the justification for Symbolic Systems hinges so critically on
studying ideas which cut across traditional disciplinary boundaries, I believe
that something should be done about this problem. My contribution was the
Symbolic Systems Forum. However, while it will promote interesting ideas
and thinking, I do not believe that the Symbolic Systems Forum will be
intense enough to solve the problem: it cannot demand reading papers, it's
more likely to get quite old ideas (say 5 years ago!), etc.
So, I have a proposal. I think that Symbolic Systems should develop a senior
seminar (perhaps with the idea of giving rise to honors projects) which
attempts some integration of all the different work going on in Symbolic
Systems. I realize that no one faculty could teach this; therefore, it should be run by several faculty. Furthermore, it could take the form of an ongoing
seminar which meets for two hours twice a week and spends two (one?
three?) weeks on each particular topic. For instance, consider the following
sequence: 2 weeks on classical AI, 2 weeks on Rosenschein's and Brooks'
work, 2 weeks on connectionism, and then 2 weeks attempting to
understand how these different ideas relate. This formulation is (of course)
loose.
There are numerous benefits. First, Symbolic Systems has a class which
attempts to build its own methodology! Second, it strikes me as a good way
of bringing in otherwise remote consulting faculty. Third, it promotes
student and faculty interaction. Fourth, everyone (student and faculty alike)
can benefit. Fifth, it might provide a very fertile ground for honors projects
(ideas and interaction with faculty.)
Of course, the major drawback is the work involved setting it up as you are
all incredibly busy. However, I think it would be worth it and (as always)
willing to talk it out with anyone and attempt to help out. Perhaps the
Symbolic Systems Program can find some lure (other than the idealized
pursuit of knowledge!) to bring in some "volunteers."
reid
p.s. there are other ways which I have considered would work on this
problem. One would be to have various faculty offer Symbolic Systems
classes: i.e. classes on representation or theory of information, etc. Anotherwould attempting to get more students involved in the research side of
Symbolic Systems for credit. While both of these would be good, I think that
that the first solution which I suggested is the best. However, these three
angles of attacking the problem are not incompatible and any combination of
them could be pursued.
-------
∂20-Nov-88 1714 FISHER@Score.Stanford.EDU teaching evals
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Nov 88 17:14:05 PST
Date: Sun 20 Nov 88 17:09:31-PST
From: Steve Fisher <FISHER@Score.Stanford.EDU>
Subject: teaching evals
To: faculty@Score.Stanford.EDU
CS-TAC 23, 723-6082
Message-ID: <12448182639.18.FISHER@Score.Stanford.EDU>
I'm sorry, but I have to disagree with Floyd's opinions on teaching
evaluations. As a recent graduate and "ephemeral lecturer" perhaps
I'm too biased toward the student's view, but since Floyd made his
opinions known, I thought I'd throw in my two cents.
It seems odd to me that anyone would think that students have no idea
what good teaching is. These people have been in school their entire
lives and they certainly have enough experience to judge their
instructors. And the myth that the easy courses are the ones that get
the good evals is exactly that. Contrary to the belief of many of the
faculty, Stanford students do want to learn and they only respect a
class that challenges them. They may sometimes take the easy classes,
but the ones that get the good evals, in my opinion, are the ones that
ask them to work hard, but reward them by the results of their work.
Ralph Gorin's CS108A,B,C sequence is just one of many examples of
very difficult classes which received excellent evals.
Of course, determining what constitutes good teaching is quite tricky.
Floyd apparently has some definition, but I don't understand how good
teaching can be going on if the student isn't learning, and poor
teaching evals indicate that the students don't believe they're
learning. Maybe some mysterious background learning process has been
set in place and the students somehow learned the material without
realizing it, but I don't believe it. These people know what they've
learned. Good teaching certainly does not consist of giving three
lectures a week and then retreating back to the ivory tower, except
maybe for a couple of office hours. You might as well replace the
instructor with a good textbook and a TA. In my opinion, good teaching
requires time, dedication, and committment. It means being willing
to treat students with respect and work with them on an individual
level. It means spending hours and hours coming up with excellent
assignments and exams, as well as informative lectures. If you don't
want to spend the time to be a good teacher, then fine. But don't
expect to be considered one.
I'll grant that students may not know if the material they have been
taught is the material they should have been taught, but to my knowledge
there hasn't been any problem with maverick instructors teaching the
wrong material. It sems obvious to me that if some class didn't prepare
students for future classwork there would have been some complaints and
a solution would have been found. In my case, I've maintained a
close relationship with many of my students and have thus been able
to get excellent feedback on how well my class prepared them for future
coursework.
Further, I certainly believe that student evals are not the ultimate
measure of good teaching. But I do believe they are a very good
measure should be taken very seriously when evaluating a teacher's
overall effectiveness.
Our department attracts a large number of excellent undergrads. The
students who just want to party don't take computer science courses.
Unfortunately, the feeling is widespread among undergrads that the CS
faculty doesn't care about undergrads, and that the faculty certainly
doesn't respect them. For the most part, I think they're right. If the
faculty doesn't even think students know good teaching when they see it,
then what do you think they know?
Steve
-------
∂21-Nov-88 0801 @Score.Stanford.EDU:chandler@polya.Stanford.EDU NSF Program Announcement
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Nov 88 08:01:24 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 21 Nov 88 07:57:07-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA08786; Mon, 21 Nov 88 07:59:42 PDT
Date: Mon, 21 Nov 1988 7:59:40 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score
Subject: NSF Program Announcement
Message-Id: <CMM.0.87.596131180.chandler@polya.stanford.edu>
Just to let you know......
I have posted a NSF program announcement " PARALLEL COMPUTING THEORY " with a
target date of 12/19/88. This is a joint NSF-DARPA initiative on parallel
computing theory.
∂21-Nov-88 0817 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Tomorrow's Faculty Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Nov 88 08:17:27 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 21 Nov 88 08:13:40-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA08907; Mon, 21 Nov 88 08:16:14 PDT
Date: Mon, 21 Nov 1988 8:16:10 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score
Subject: Tomorrow's Faculty Lunch
Message-Id: <CMM.0.87.596132171.chandler@polya.stanford.edu>
Just a reminder...
John Mitchell will lead a discussion about opportunities and challenges for
junior faculty in the Department at tomorrow's faculty lunch at 12:15 in
MJH-146. See you there!
∂21-Nov-88 0834 @Score.Stanford.EDU:DEK@SAIL.Stanford.EDU Another Thursday Feast
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Nov 88 08:34:03 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 21 Nov 88 08:30:11-PST
Message-ID: <dE7PN@SAIL.Stanford.EDU>
Date: 21 Nov 88 0832 PST
From: Don Knuth <DEK@SAIL.Stanford.EDU>
Subject: Another Thursday Feast
To: faculty@SCORE.STANFORD.EDU, sf@CSLI.STANFORD.EDU, sarnak@GAUSS.Stanford.EDU,
veinott@SIERRA.Stanford.EDU
Jill and I are hosting a dinner party on Thursday evening, December 8,
in honor of Tom Leighton who will be visiting our department on the
8th and 9th. Spouses/significantothers are also invited to come.
However, we can't accommodate anywhere near the whole faculty, so we must
limit the guests to a maximum of 25. I think FIFO order is the only reasonable
solution to this queueing problem; so:
We hereby invite the first 25 people who respond to PHY @ SAIL
to a tasty meal at the home of Don and Jill Knuth,
1063 Vernier Place, Stanford, 8 December 1988 at 6pm.
[If your response indicates that you will bring a guest, that counts
as 2 of the 25; but don't hesitate on those grounds! We do want to encourage
couples to come together; this is a social not technical occasion.]
Anybody who wants to set up an appointment to meet with Tom during the
day either Thursday or Friday should schedule that with Phyllis too.
Tom will be staying at the Faculty Club.
-- Don
∂21-Nov-88 0852 TAJNAI@Score.Stanford.EDU Nominees for Bell Fellowship - call for vote
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Nov 88 08:52:02 PST
Date: Mon 21 Nov 88 08:48:04-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Nominees for Bell Fellowship - call for vote
To: faculty@Score.Stanford.EDU
Message-ID: <12448353498.12.TAJNAI@Score.Stanford.EDU>
Please vote on the following candidates. They are the only first and
second year students who are eligible to be nominated for the Bell
Fellowship (a four year fellowship).
Immediate attention to this would be appreciated.
Carolyn
Rebecca Moore second-year PHD
Jennifer-Ann Anderson the first-year students
Roland Conybeare
Andy Hung
Morris Katz
James Kennedy
Alon Levy
Patrick Lincoln
Daniel Scales
Michael Young
-------
∂21-Nov-88 0901 TAJNAI@Score.Stanford.EDU Bell Fellowship nominees -- one more
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Nov 88 09:01:49 PST
Date: Mon 21 Nov 88 08:58:03-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Bell Fellowship nominees -- one more
To: faculty@Score.Stanford.EDU
Message-ID: <12448355315.12.TAJNAI@Score.Stanford.EDU>
Dror Maydan is also eligible.
Carolyn
-------
∂21-Nov-88 0949 LOGMTC-mailer Seminar
To: logmtc@SAIL.Stanford.EDU
From: Carolyn Talcott <CLT@SAIL.Stanford.EDU>
Speaker: Yukiyoshi Kameyama (Tohoku University)
(visiting Stanford 27 Nov to 16 Dec)
Title: Programming/Proving System in SST
(Joint work with Prof. Masahiko Sato.)
Time: 4pm, Tuesday December 6, 1988
Place: 352 Margaret Jacks Hall, Stanford
Abstract:
We are mainly interested in developing a proving/programming
system on computer. To do so, we present a functional programming
language Lambda and a constructive logical system SST, Symbolic
Set Theory. Lambda is intended to be an object language and a
meta language of SST; Namely, a Lambda program is verified in
SST naturally (since a Lambda program is just a closed term in SST),
and at the same time, a proof-system of SST will be implemented
on top of Lambda. We, then, will be able to prove the correctness
of the proof-system using the system itself, and some meta-theorems
within SST.
∂21-Nov-88 0952 TAJNAI@Score.Stanford.EDU Corrected list of eligible candidates for Bell
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Nov 88 09:50:58 PST
Date: Mon 21 Nov 88 09:45:50-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Corrected list of eligible candidates for Bell
To: faculty@Score.Stanford.EDU
Message-ID: <12448364014.12.TAJNAI@Score.Stanford.EDU>
This is a corrected list. I just learned that Kanamori has permanent
residence.
.................
Please vote on the following candidates. They are the only first and
second year students who are eligible to be nominated for the Bell
Fellowship (a four year fellowship).
Immediate attention to this would be appreciated.
Carolyn
Rebecca Moore second-year PHD
Jennifer-Ann Anderson the first-year students
Roland Conybeare
Andy Hung
Atsushi Kanamori
Morris Katz
James Kennedy
Alon Levy
Patrick Lincoln
Dror Maydan
Daniel Scales
Michael Young
-------
∂21-Nov-88 1142 barwise@russell.Stanford.EDU Breaking the code
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Nov 88 11:42:47 PST
Received: from localhost by russell.Stanford.EDU (4.0/4.7); Mon, 21 Nov 88 11:39:05 PST
To: ssp-students@russell.Stanford.EDU, ssp-faculty@russell.Stanford.EDU
Subject: Breaking the code
Date: Mon, 21 Nov 88 11:39:02 PST
From: Jon Barwise <barwise@russell.Stanford.EDU>
Sol Feferman tells me that "Breaking the code" is playing at the Magic
Theater in SF. The play is taken from the biography of Alan Turing.
It contains the best simple description of Godel's Theorem I know. It
is also a fascinating play. I saw it in NY and Sol says this
production is first-rate. Maybe someon wants to organize an SSP field
trip to see it? It is on until Dec 18. The box office is 441-8822.
Of just go by yourselves. The Magic Theater is a very interesting
group. You should eat at Green's while you are there. They are at
more or less the same place.
∂21-Nov-88 1429 nilsson@Tenaya.stanford.edu Breaking the code
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Nov 88 14:29:16 PST
Received: from Tenaya.stanford.edu by russell.Stanford.EDU (4.0/4.7); Mon, 21 Nov 88 14:26:33 PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA04687; Mon, 21 Nov 88 14:23:06 PDT
Date: Mon, 21 Nov 88 14:23:06 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8811212223.AA04687@Tenaya.stanford.edu>
To: barwise@russell.Stanford.EDU
Cc: ssp-students@russell.Stanford.EDU, ssp-faculty@russell.Stanford.EDU
In-Reply-To: Jon Barwise's message of Mon, 21 Nov 88 11:39:02 PST <8811211946.AA04629@Tenaya.stanford.edu>
Subject: Breaking the code
I saw "breaking the code" at the Magic Theatre last night. It's
excellently done with first-class acting. Do go! (Besides the
bit about consistency/completeness/decideability there are some
nice arguments in favor of AI.) -Nils
∂21-Nov-88 1920 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu FOCS88 registration list
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Nov 88 19:20:24 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA29049; Mon, 21 Nov 88 19:20:06 PDT
Message-Id: <8811220320.AA29049@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 21 Nov 88 19:20:04 PST
Received: by BYUADMIN (Mailer R2.01) id 8596; Mon, 21 Nov 88 20:16:14 MST
Date: Mon, 21 Nov 88 14:15:51 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Victor S. Miller" <VICTOR%YKTVMX.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: "Victor S. Miller" <VICTOR%YKTVMX.BITNET@forsythe.stanford.edu>
Subject: FOCS88 registration list
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
I am placing (courtesy of Alok Aggarwal and Nancy Perry of IBM Research,
Yorktown) the FOCS '88 list of registered attendees (with addresses, phones
and e-mail addresses if provided) in the list of available files on LISTSERV.
The file is rather large (over 3300 lines) so I didn't send it to every
subscriber to Theory Net. If you wish to retrieve it you may do one of
the following:
Send mail to LISTSERV@NDSUVM1 (on bitnet) or listserv@vm1.nodak.edu
whose body consists of the line
GET FOCS88 PEOPLE
If you are on the internet and have FTP available, you may ftp to the site
vm1.nodak.edu, userid ANONYMOUS, password guest. The file
focs88.people is contained in the directory listarch.
The file may not appear until tomorrow (22 Nov) because of delays in the
bitnet network.
Soon (as soon as I can figure it out), the file will also be available for
querying by means of the database function of listserv. You can find out
more about the latter by sending mail to listserv@ndsuvm1 or
listserv@vm1.nodak.edu whose body consists of the line
INFO DATABASE
Victor
∂21-Nov-88 1924 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Drawing sets
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Nov 88 19:23:59 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA29177; Mon, 21 Nov 88 19:23:47 PDT
Message-Id: <8811220323.AA29177@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 21 Nov 88 19:23:47 PST
Received: by BYUADMIN (Mailer R2.01) id 8986; Mon, 21 Nov 88 20:22:40 MST
Date: Mon, 21 Nov 88 18:32:30 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Phillip Yelland <pmcy%JENNY.CL.CAM.AC.UK@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Phillip Yelland <pmcy%JENNY.CL.CAM.AC.UK@Forsythe.Stanford.EDU>
Subject: Drawing sets
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Here's a diverting little problem; I wonder if I might presume upon
the good offices of net-landers to aid in its solution.
I am given a collection of (non-disjoint) sets. The task is to represent
these sets as rectangles on a plane, with rectangles over-lapping where the
intersections between their corresponding sets are non-empty (or, indeed, to
establish that such a drawing is impossible). So for example, given:
A = {1, 2, 4}
B = {2, 3, 4}
C = {3, 4, 5}
one possible rendering might look something like:
+----A----+
| 1 |
| +----B----+
| | 2 | |
| | +----C----+
| | | 4| | |
+---|-----+ | |
| | 3 | |
+---------+ |
| 5 |
+---------+
I do have several algorithms for this, but most operate on a brute-force-and-
ignorance basis, and all are exponential in the number of sets. Am I missing
something? (An analogy with graph planarization, for example?) Or is the
problem NP (hard/complete)? Suggestions, references, tales of woe, etc. would
all be most gratefully received.
Many thanks, in advance.
Phillip M. Yelland (pmcy@uk.ac.cam.cl)
∂21-Nov-88 2352 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu computational geometry symposium
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Nov 88 23:52:12 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA12124; Mon, 21 Nov 88 23:51:51 PDT
Message-Id: <8811220751.AA12124@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 21 Nov 88 23:51:52 PST
Received: by BYUADMIN (Mailer R2.01) id 7168; Tue, 22 Nov 88 00:50:32 MST
Date: Tue, 22 Nov 88 01:06:21 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Micha Sharir <sharir%ACF8.NYU.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Micha Sharir <sharir%ACF8.NYU.EDU@Forsythe.Stanford.EDU>
Subject: computational geometry symposium
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
CALL FOR PAPERS
Fifth Annual ACM Symposium on
COMPUTATIONAL GEOMETRY
5-7 June 1989
Universitat des Saarlandes
Saarbrucken, West Germany
Papers presenting original research in
computational geometry are being sought. Suggested
topic areas include (but are not limited to):
* design and analysis of geometric algorithms
* data structures for computational geometry
* applications with a geometric flavor, including
-- robotics: collision avoidance, motion planning, grasping
-- computer graphics: hidden surface and rendering algorithms
-- solid modeling, CAD, simulation
-- pattern recognition: shape decomposition
* mathematical basis for computational geometry
* issues arising from the implementation of geometric algorithms
* programming language issues in computational geometry
Authors should send ten (10) copies of an extended abstract by
DECEMBER 8, 1988
to the Program Committee Chair:
Micha Sharir
Courant Institute of Mathematical Sciences
New York University
251 Mercer Street
New York, NY 10012
Abstracts received past this deadline risk rejection
without further consideration.
Authors will be notified of acceptance or rejection by February
6, 1989. A copy of each accepted paper, typed on model paper, will be due
by March 16, 1989, for inclusion in the proceedings.
Authors are advised to prepare their extended abstracts carefully.
Each submission should begin with a succinct
statement of the problems, the main results, and the
significance of the work in the context of previous research.
The extended abstract (not a full paper)
should provide sufficient detail
to allow the program committee to evaluate the quality of the
contribution and its appropriateness to the
conference. The entire extended abstract should not exceed
10 double-spaced pages. Abstracts significantly deviating from this
format risk rejection without consideration of their merits.
The Symposium is sponsored by ACM SIGACT and SIGGRAPH, and by EATCS.
Proceedings will be distributed at the Symposium and will be
subsequently available for purchase from ACM.
In addition to the technical program, a summer school in computational
geometry will be held in the week preceding the conference, where
tutorials given by leading researchers will survey the
state of the art in the field.
For more information, please contact the conference chair,
Kurt Mehlhorn, at the address below.
Symposium Committees
Program Committee Conference Chair
Richard Bartels D.T. Lee Kurt Mehlhorn
John Canny Nimrod Megiddo Fachbereich 10 Informatik
Kenneth Clarkson Mark Overmars Universitat des Saarlandes
Leonidas Guibas Janos Pach 6600 Saarbrucken
Christoph Hoffman Micha Sharir West Germany
∂22-Nov-88 0734 @Score.Stanford.EDU:tom@polya.Stanford.EDU Dover
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Nov 88 07:34:03 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 22 Nov 88 07:30:39-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA01515; Tue, 22 Nov 88 07:33:16 PDT
Date: Tue, 22 Nov 88 07:33:16 PDT
From: Tom Dienstbier <tom@polya.Stanford.EDU>
Message-Id: <8811221533.AA01515@polya.Stanford.EDU>
To: csd@score, faculty@score, su-computers@score
Subject: Dover
Dover will be put to rest December 31,1988. This will complete the phasing
out of the older Dovers. In its place, CSDCF has provided printing on
two DEC laser printers(LPS40), called Zsego and Elm.
∂22-Nov-88 1004 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu vis com report
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Nov 88 10:04:10 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 22 Nov 88 09:59:47-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA05278; Tue, 22 Nov 88 10:01:07 PDT
Date: Tue, 22 Nov 88 10:01:07 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8811221801.AA05278@Tenaya.stanford.edu>
To: faculty@score
Subject: vis com report
We now have, at long last, the official report of the CSD visiting
committee resulting from their thorough review of us last February.
Anyone who would like a copy can get one from Joyce Chandler. -Nils
∂22-Nov-88 1009 LOGMTC-mailer note
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Nov 88 10:09:41 PST
Received: from localhost by russell.Stanford.EDU (4.0/4.7); Tue, 22 Nov 88 10:11:54 PST
To: logic@russell.Stanford.EDU
Subject: note
Date: Tue, 22 Nov 88 10:11:51 PST
From: Jon Barwise <barwise@russell.Stanford.EDU>
I am not sure what this is about, but thought I would pass it along.
------- Forwarded Message
Return-Path: lacey@csli.Stanford.EDU
Received: from csli.Stanford.EDU by russell.Stanford.EDU (4.0/4.7); Tue, 22 Nov 88 09:00:27 PST
Received: by csli.Stanford.EDU (4.0/4.7); Tue, 22 Nov 88 08:56:43 PST
Date: Tue 22 Nov 88 08:56:42-PST
From: Marti Lacey <LACEY@CSLI.Stanford.EDU>
Subject: Special Lecture- A Reminder
To: phil-all@csli.Stanford.EDU
Message-Id: <596221002.0.LACEY@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Who: Professor Vladimir Smirnov, Institute of Philosophy, Soviet Academy
of Sciences, Moscow
When: TODAY, November 22, 1988, 4:15 pm
Where: Ventura Seminar Room
Title: "External and Internal Logics"
**TEA WILL BE HELD AT 3:45 IN THE VENTURA LOUNGE**
- -------
------- End of Forwarded Message
∂22-Nov-88 1046 helen@russell.Stanford.EDU courses
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Nov 88 10:45:34 PST
Received: by russell.Stanford.EDU (4.0/4.7); Tue, 22 Nov 88 10:46:31 PST
Date: Tue 22 Nov 88 10:46:28-PST
From: Helen Nissenbaum <HELEN@CSLI.Stanford.EDU>
Subject: courses
To: ssp-faculty@russell.Stanford.EDU
Message-Id: <596227588.0.HELEN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Please let us know if you hear of any courses, not already listed by us,
that may be of interest to SSP majors.
Thanks,
Helen.
-------
∂22-Nov-88 1050 @Score.Stanford.EDU:goldberg@Jinn.stanford.edu VISITING PROFs
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Nov 88 10:50:15 PST
Received: from Jinn.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 22 Nov 88 10:45:56-PST
Received: by Jinn.stanford.edu (4.0/25-eef) id AA02678; Tue, 22 Nov 88 10:48:54 PST
Date: Tue, 22 Nov 88 10:48:54 PST
From: Andrew Goldberg <goldberg@Jinn.stanford.edu>
Message-Id: <8811221848.AA02678@Jinn.stanford.edu>
To: faculty@score
Subject: VISITING PROFs
The visiting professors committee recommends Visiting Industrial
Lectureships and recommends and approves Departmental Visiting
Professors for the Computer Science Department.
The department has funds for one half of a visiting professor salary
per academic year. It also has funds for one Industrial Lecturer per
quarter. For these positions, we would like high-quality
candidates, people of the same stature and abilities that we would
want to have as regular faculty members. An ideal candidate is
someone who will stimulate research and who will be able to help out
with teaching. The teaching load for Visitoring Professors is two or
three courses per year, depending on a particular case (e.g., summer
support by the department). We would like the Visiting Industrial
Lecturers to teach a course during the quarter that they are here.
It is possble to hire more then one person, given supplementary
funding. For example, this year Gurevich and Linial have part-time
visiting positions here and part-time visiting positions at IBM.
This year, the visiting professor/lecturer committee consists of
Goldberg (chair), Gupta, Sloan, and Wheaton.
If you know a good candidate, please encourage her/him to send a Vita
to me.
--Andy Goldberg
∂22-Nov-88 1438 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Parallel Computing
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Nov 88 14:38:13 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 22 Nov 88 14:34:05-PST
Message-ID: <18ExeK@SAIL.Stanford.EDU>
Date: 22 Nov 88 1436 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Parallel Computing
To: faculty@SCORE.Stanford.EDU
CC: ball@Polya.Stanford.EDU, ME@SAIL.Stanford.EDU, grossman@Polya.Stanford.EDU,
farhad@Polya.Stanford.EDU, tom@Polya.Stanford.EDU
Reply-To: ARK@SAIL.STANFORD.EDU
I am willing to coordinate the process of submitting a grant proposal to
NSF for the joint NSF-DARPA initiative in Parallel Computing Theory. My
intent is to propose obtaining a parallel computer along with support
money for a year. I do not intend to ask for researcher salaries, merely
some programmer support salaries and maintenance money for a year.
I am soliciting faculty members who would like to use this resource and
will write up a blurb indicating what they would do with it were it here.
There is currently an Alliant (belonging to McCarthy), a Sequent
(belonging to Luckham and McCluskey (?)), and a Cydrum (belonging to
Oliger). Connection machines are available on the net, through such
resources as the Northeast Parallel Architectures Center at Syracuse
University. I think it would be interesting to get a parallel computer
with a hierarchical shared memory, such as a BBN Butterfly, as this is an
architecture to which we do not yet have access here.
I suggest we get hardware costing a total of about $150K, and that support
costs would be about $100K including overhead, for a grant application
totalling $250K. The total amount of money available is about $1.5
million in FY 89.
Please send me a message indicating your level of interest, if any.
Arthur
∂22-Nov-88 1521 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Responses to query by Yelland
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Nov 88 15:20:50 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA02016; Tue, 22 Nov 88 15:20:17 PDT
Message-Id: <8811222320.AA02016@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 22 Nov 88 15:20:15 PST
Received: by BYUADMIN (Mailer R2.01) id 4422; Tue, 22 Nov 88 16:18:26 MST
Date: Tue, 22 Nov 88 14:44:42 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: "Victor Miller -- moderator, Theory Net" <THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu>
Subject: Responses to query by Yelland
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
The following three responses were received to the query by Phillip
Yelland:
------------------
Date: 20 Nov 88 19:16:00 GMT
From: m.cs.uiuc.edu!p.cs.uiuc.edu!gillies@uxc.cso.uiuc.edu
Subject: Re: Drawing sets
If you are willing to relax your problem, then it is probably pretty easy
to draw sets in the plane. The relaxation is to draw "blobs" instead
of rectangles for the set boundaries:
For a given number of sets and intersections, construct a graph
with one vertex per set, and an edge for each intersection.
Now if your graph is non-planar, halt and output "impossible".
Otherwise, construct a planar embedding of the graph, and for
each vertex with edges e1..ej, draw a convex blob that surrounds
each vertex and covers slightly more than half of each edge.
Then, you'll get a graph of "stars" with the desired properties.
I don't know if when you can perturb this graph into one with just
rectangles, or perhaps with rectangles and circles, etc.
Don Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801
ARPA: gillies@cs.uiuc.edu UUCP: {uunet,harvard}!uiucdcs!gillies
------------------
Date: 22 Nov 88 05:14:12 GMT
From: polya!ramsey@labrea.stanford.edu (Ramsey W. Haddad)
Organization: Computer Science Department
Subject: Re: Drawing sets
Message-Id: <5223@polya.Stanford.EDU>
References: <382@scaup.cl.cam.ac.uk>, <100600008@p.cs.uiuc.edu>
In article <100600008@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes:
>
>If you are willing to relax your problem, then it is probably pretty easy
>to draw sets in the plane. The relaxation is to draw "blobs" instead
>of rectangles for the set boundaries:
>
> For a given number of sets and intersections, construct a graph
> with one vertex per set, and an edge for each intersection.
> Now if your graph is non-planar, halt and output "impossible".
> Otherwise, construct a planar embedding of the graph, and for
> each vertex with edges e1..ej, draw a convex blob that surrounds
> each vertex and covers slightly more than half of each edge.
>
This is incorrect. If arbitrary blobs are allowed then an answer
always exists even if the blobs must all be of the same shape.
Problem 1.22 from "Concrete Math" by Graham, Knuth & Patashnik is:
"Show that it's possible to construct a Venn diagram for all 2~n
possible subsets on n given sets using n convex polygons that are
congruent to each other and rotated about a commmon center." After
constructing such a Venn diagram, it is easy to solve this problem for
any sets.
Answer: "Take a regular polygon with 2~n sides and label the sides
with the elements of a "de Bruijn cycle" of length 2~n. (This is a
cyclic sequence of 0's and 1's in which all n-tuples of adjacent
elements are different). Attach a very thin convex extension to each
side that's labeled 1. The sets are copies of the resulting polygon,
rotated by the length of k sides, for k = 0, 1, ... n-1."
--
Ramsey W Haddad
------------------
From: dsj@research.att.com
Date: Tue, 22 Nov 88 14:35:28 EST
Subject: representing sets by rectangles
I believe the problem posed by Phillip M. Yelland about representing
sets by rectangles is one of several that Henry Pollak and I proved
NP-complete in "Hypergraph planarity and the complexity of drawing Venn
diagrams," J. GRAPH THEORY 11 (1987), 309-326.
David Johnson (dsj@research.att.com)
∂22-Nov-88 1611 @Score.Stanford.EDU:chandler@polya.Stanford.EDU NSF Fiscal Year 1987 Summary of Awards
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Nov 88 16:11:42 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 22 Nov 88 16:07:20-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA05318; Tue, 22 Nov 88 16:09:53 PDT
Date: Tue, 22 Nov 1988 16:09:51 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score
Subject: NSF Fiscal Year 1987 Summary of Awards
Message-Id: <CMM.0.87.596246991.chandler@polya.stanford.edu>
I have the subject publication in my office. If you'd like to look at it,
please feel free to stop by.
∂23-Nov-88 0930 @Score.Stanford.EDU:chandler@polya.Stanford.EDU January 10 Faculty Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Nov 88 09:30:37 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 23 Nov 88 09:26:13-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA20922; Wed, 23 Nov 88 09:28:48 PDT
Date: Wed, 23 Nov 1988 9:28:45 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score
Cc: chandler@polya.Stanford.EDU
Subject: January 10 Faculty Meeting
Message-Id: <CMM.0.87.596309325.chandler@polya.stanford.edu>
There will be a faculty meeting held in room 146 of MJH on January 10, 1989
at 2:30 - 4:00. Please send me any items you would like to have put on the agenda.
∂23-Nov-88 0949 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Bill Gates Visit
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Nov 88 09:49:56 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 23 Nov 88 09:45:34-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA06056; Wed, 23 Nov 88 09:46:51 PDT
Date: Wed, 23 Nov 88 09:46:51 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8811231746.AA06056@Tenaya.stanford.edu>
To: faculty@score
Subject: Bill Gates Visit
Bill Gates of Microsoft will be visiting Stanford on Thursday,
December 1. He will be giving a lecture in Memorial Auditorium at
noon that day. This talk is being organized, I think, by students in
the Graduate School of Business. More information about this talk
will be forthcoming.
Jim Gibbons and I have visitied Bill at the Microsoft HQ, and he
expressed a great interest in Stanford and knew something already
about many of the CS faculty. Needless to say, he is an important
personality to the Stanford Centennial Campaign fund raisers and
perhaps for our own fund-raising needs. (The Gates Computer Science
Building?)
I had previously mentioned to several of you that Gates would like to
meet some of us. The names I remember contacting about this were
Ullman, Knuth, Cheriton, Hennessy, Latombe, McCarthy, and Feigenbaum.
I think many of you said that you would put the day on your calendars.
We (in CS/CSL) will have Gates from 2:00 to 4:00 pm that day, Dec. 1.
The format that I suggest is that we meet in my conference room (MJH
220) from 2 to 4 and talk informally about the spectrum of research
going on in CS/CSL. No prepared talks but, say, 10-15 minute
discussion-provoking overviews by some of you of what you are up to
followed by 10 mins or so of discussion. That would leave time for
maybe five or so such talks spanning some of the work in the Dept.
What I need now is an indication from the above-named people
especially (namely, Ullman, Knuth, Cheriton, Hennessy, Latombe,
McCarthy, and Feigenbaum) about whether they would be able to lead one
of these "mini-talks." It would also be appropriate for any other
faculty members who would like to participate to let me know.
Responders please let me know about any time constraints that would
affect their participation. All participants are welcome to stay for
the entire two-hour event or just pop in for their time-slot.
I had also previously mentioned that their might be a Gates dinner
that evening. That has been cancelled since Gates will be returning
to Seattle at about 5 pm.
Thanks,
-Nils
∂23-Nov-88 1008 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu junior faculty
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Nov 88 10:08:12 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 23 Nov 88 09:55:17-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA06063; Wed, 23 Nov 88 09:56:36 PDT
Date: Wed, 23 Nov 88 09:56:36 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8811231756.AA06063@Tenaya.stanford.edu>
To: tenured@score
Subject: junior faculty
One cannot but be impressed by the quality and energy of our junior
faculty. The faculty lunch discussion yesterday was very helpful, I
think, in impressing upon all of us the importance of providing
conditions for them to blossom. One thing that several of them have
mentioned to me, to our visiting committee last February, and to the
lunch group yesterday was their need for contact with older faculty
members. I hope all of us will pay special attention to this need and
be responsive to their requests for guidance about proposals,
teaching, advising, etc.
Thanks, -Nils
∂23-Nov-88 1821 lansky@ai.sri.com SRI AIRR Seminar (aka PLANLUNCH) : Next Tuesday -- Yoav Shoham
Received: from Warbucks.AI.SRI.COM by SAIL.Stanford.EDU with TCP; 23 Nov 88 18:21:48 PST
Received: from venice.ai.sri.com by Warbucks.AI.SRI.COM with INTERNET ;
Wed, 23 Nov 88 18:03:33 PST
Received: by venice.ai.sri.com (3.2/4.16)
id AA05193 for planlunch@ai.sri.com; Wed, 23 Nov 88 18:03:32 PST
Date: Wed, 23 Nov 88 18:03:32 PST
From: lansky@Warbucks.AI.SRI.COM (Amy Lansky)
Message-Id: <8811240203.AA05193@venice.ai.sri.com>
To: planlunch@Warbucks.AI.SRI.COM
Subject: SRI AIRR Seminar (aka PLANLUNCH) : Next Tuesday -- Yoav Shoham
Next week we will renew our ongoing seminar series with a new name
and time slot: the SRI AIRR (AI Representation and Reasoning) Seminar.
(The subject matter of planning and time-frame of "lunch" was getting
a bit too narrow!)
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
SOME LESSONS FROM NOTATIONAL ENGINEERING
Yoav Shoham (SHOHAM@SCORE.STANFORD.EDU)
Stanford University
2:00 PM, TUESDAY, November 29
SRI International, Building E, Room EJ228
Two instances are given where notational hacking has led to insight
into conceptual matters. In the first, we show how attempts to define
the concept of action in the context of temporal logics resulted in
identifying a close connection between action, knowledge and free
will. In the second, we show how attempts to combine the notions of
knowledge and belief in the same framework have resulted in a reversal
of a philosophical maxim: rather than view knowledge as an elevated
form of belief, we view belief as a defeasable form of knowledge.
This latter work was carried out jointly with Yoram Moses.
∂23-Nov-88 2024 LOGMTC-mailer seminar
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Nov 88 20:23:57 PST
Received: by csli.Stanford.EDU (4.0/4.7); Wed, 23 Nov 88 20:22:53 PST
Date: Wed 23 Nov 88 20:22:52-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: seminar
To: logic@csli.Stanford.EDU
Message-Id: <596348572.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Seminar in Logic and Foundations
Speaker: Paolo Mancosu
Title: "Generalizing classical and effective analogues for model theory"
Time: Monday, Nov. 28, 4:15-5:30 PM
Place: Room 381-T, Math Bldg, Stanford
Mancosu will speak twice, the second time on Dec. 12. Our speaker Dec 5
will be Douglas Bridges, who will speak on constructive measure theory.
S. Feferman
-------
∂28-Nov-88 0817 LOGMTC-mailer Seminar (change of time)
To: logmtc@SAIL.Stanford.EDU
From: Carolyn Talcott <CLT@SAIL.Stanford.EDU>
Speaker: Yukiyoshi Kameyama (Tohoku University)
(visiting Stanford 27 Nov to 16 Dec)
Title: Programming/Proving System in SST
(Joint work with Prof. Masahiko Sato.)
Time: 11am, Tuesday December 6, 1988
Place: 352 Margaret Jacks Hall, Stanford
Abstract:
We are mainly interested in developing a proving/programming
system on computer. To do so, we present a functional programming
language Lambda and a constructive logical system SST, Symbolic
Set Theory. Lambda is intended to be an object language and a
meta language of SST; Namely, a Lambda program is verified in
SST naturally (since a Lambda program is just a closed term in SST),
and at the same time, a proof-system of SST will be implemented
on top of Lambda. We, then, will be able to prove the correctness
of the proof-system using the system itself, and some meta-theorems
within SST.
∂28-Nov-88 0839 TAJNAI@Score.Stanford.EDU final round for Bell Fellowship Nomination
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 08:39:40 PST
Date: Mon 28 Nov 88 08:36:45-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: final round for Bell Fellowship Nomination
To: faculty@Score.Stanford.EDU
Message-ID: <12450186445.22.TAJNAI@Score.Stanford.EDU>
We need a decision by Thursday, Dec. 1. Vote for 3:
Roland Conybeare (first year)
Atsushi Kanamouri (first Year)
Morris Katz (first Year)
Patrick Lincoln (first year)
Dror Maydan (first year)
Rebecca Moore (second year)
Daniel Scales (first year)
Carolyn
-------
∂28-Nov-88 0957 delagi@sumex-aim.stanford.edu
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 28 Nov 88 09:56:56 PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA22693; Mon, 28 Nov 88 09:53:45 PST
Date: Mon, 28 Nov 1988 9:53:44 PST
From: Bruce Delagi <delagi@sumex-aim.stanford.edu>
To: aap@sumex-aim.stanford.edu
Message-Id: <CMM.0.88.596742824.delagi@sumex-aim.stanford.edu>
Return-Path: <fpst@hubcap.clemson.edu>
Received: from RELAY.CS.NET (GW1.CS.NET) by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA19264; Wed, 23 Nov 88 18:14:24 PST
>From: fpst@hubcap.clemson.edu
Received: from hubcap.clemson.edu by RELAY.CS.NET id aa13321; 23 Nov 88 8:43 EST
Received: by hubcap.clemson.edu; Wed, 23 Nov 88 08:24:04 est
Date: Wed, 23 Nov 88 08:24:04 est
Message-Id: <8811231324.AA05930@hubcap.clemson.edu>
To: DELAGI%SUMEX-AIM.Stanford.EDU@relay.cs.net,
coraki!pratt%Sun.COM@relay.cs.net, cvb%daresbury.ac.uk@relay.cs.net,
develo%waikato.ac.nz@relay.cs.net, dwk%cs.tufts.edu@relay.cs.net,
gopalakr%enuxha.asu.edu@relay.cs.net,
hcube-users%hamlet.caltech.edu@relay.cs.net,
hcube-users%mtu.edu@relay.cs.net, scherrer%lovada.dec.com@relay.cs.net,
zenith%inmos.uucp@relay.cs.net
>From: Eugene Miya <eugene@orville.nas.nasa.gov>
Subject: Caltech hypercube conference volume II
Newsgroups: comp.parallel
Approved: parallel@hubcap.clemson.edu
Unfortunately, a colleague has had time to make his annotations so I'm
posting Cube volume II. I'm not currently working on Cubes, so
I am not planning to be in Monterey. SC'88 in a week or so.
This will be the last conference for the year for me. I would personally
like to thank all the net hackers I met in Florida.
%A Geoffrey C. Fox
%Z Caltech
%T What Have We Learnt from Using Real Parallel Machines to Solve
Real Problems?
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 897-955
%r cccp-522
%K review, survey, speculation, (not strict) domain decomposition,
%X Cocktail/dinner/conference keynote speech. This paper presents
yet another taxonomy of parallelism. What is interesting about this taxonomy
is that it tries to includes a taxonomy of applications so that better
algorithm to architecture matching might take place:
machine: 1. multicomputers, 2. shared memory, 3. SIMD; algorithms:
S == synchronous, PLS == properly loosely synchronous,
PA == properly asynchronous, EP-S == embarrassingly parallel,
seemingly suitable for SIMD [this is a good category], EP-M ==
embarrassingly parallel seemingly requires MIMD.
Foxes then scores entire disciplines: physics, chemistry, CS, etc.
A large reference list.
%A Peter Gorham
%A Thomas Prince
%A Stuart Anderson
%Z Caltech
%T Hypercube Data Analysis in Astronomy: Optical Interferometry and
Millisecond Pulsar Searches
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 957-962
%r cccp-571
%K applications in astronomy and astrophysics, NCUBE, VLBI,
%A John Apostolakis
%A Christopher S. Kochanek
%Z Caltech
%T Statistical Gravitational Lensing on the Mark III Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 963-970
%r cccp-581
%K applications in astronomy and astrophysics, ray-tracing,
parallel algorithm,
%A Mike Warren
%A John Salmon
%Z Caltech
%T An O(N log N) Hypercube N-Body Integrator
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 971-975
%r cccp-593
%K applications in astronomy and astrophysics, FFT, decomposition,
CrOS, crystal router,
%A J. M. Bower
%A M. E. Nelson
%A M. A. Wilson
%A G. C. Fox
%A W. Furmanski
%Z Caltech
%T Piriform (Olfactory) Cortex Model on the Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 977-999
%r cccp-404B
%K applications in biology, robotics, and vision, neurophysiology,
folding algorithm, NCUBE, neural network,
%A Roberto Battiti
%Z Caltech
%T Collective Stereopsis on the Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1000-1006
%r cccp-583
%K applications in biology, robotics, and vision, CrOS III, neural
network,
correspondence of random points,
%A Alan H. Bond
%A David Fashena
%Z Caltech
%T Parallel Vision Techniques on the Hypercube Computers
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1007-1010
%r cccp-632
%K applications in biology, robotics, and vision, image analysis,
edge finding and detection, histogram,
%A Alex Ho
%A Wojtek Furmanski
%Z Caltech
%T Pattern Recognition by Neural Network Model on Hypercubes
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1011-1021
%r cccp-528
%K applications in biology, robotics, and vision, perceptron, AI,
image processing, Chinese characters, Mark III,
%A Judson P. Jones
%Z ORNL
%T A Concurrent On-Board Vision System for a Mobile Robot
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1022-1032
%K applications in biology, robotics (HERMIES), and vision, NCUBE,
VME,
Hough transform, image processing, component classification,
%A Marc Willebeek-LeMair
%A Anthony P. Reeves
%T Region Growing on a Hypercube Multiprocessor
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1033-1042
%K applications in biology, robotics, and vision, iPSC, MIMD, image,
homogeneity, parallel split/merge, dynamic load balancing,
%A Hong-Qiang Ding
%Z Caltech
%T Polymer Simulation on the Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1044-1050
%r cccp-574
%K applications in chemistry and chemical engineering, Mark III,
CrOS, Monte Carlo,
%A Paul G. Hipes
%A Tim Mattson
%A Mark Y.-S. Wu
%A Aron Kuppermann
%Z Caltech
%T Chemical Reaction Dynamics: Integration of Coupled Sets of
Ordinary Differential Equations on the Caltech Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1051-1061
%r cccp-570
%K applications in chemistry and chemical engineering,
SHC (symmetrized hyperspherical coordinates),
local surface functions (LHSF),
%A Anthony Skjellum
%A Manfred Morari
%Z Caltech
%A Sven Mattisson
%T Waveform Relaxation for Concurrent Dynamic Simulation of
Distillation Columns
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1062-1071
%r cccp-588
%K applications in chemistry and chemical engineering, CONCISE,
VLSI, circuit simulation, TRAY,
%A John Bruno
%A Peter R. Cappello
%Z UCSB
%T Implementing the Beam and Warming Method on the Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1073-1087
%K applications in engineering, fluid dynamics, CFD, implicit
factoring,
cell to node mapping,
%X Interesting: no references.
%A Ruel H. Calalo
%A James R. Lyons
%A William A. Imbriale
%Z JPL
%T Finite Difference Time Domain Solution of Electromagnetic
Scattering
on the Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1088-1100
%r cccp-596
%K applications in engineering, FDTD, radar cross-section (RCS),
Maxwell's equations, Mark III, EM, parallel decomposition,
%A Paulett C. Liewer
%A Viktor K. Decyk
%A John M. Dawson
%A Geoffrey C. Fox
%T A Universal Concurrent Algorithm for Plasma Particle-in-Cell
Simulation Codes
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1101-1107
%r cccp-362
%K applications in engineering, UC-PIC, Mark III, FFT,
%X Compared with several supercomputers (Crays).
%A F. Ozguner
%A C. Aykanat
%A O. Khalid
%Z OSU
%T Logic Fault Simulation on a Vector Hypercube Multiprocessor
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1108-1116
%K applications in engineering, VLSI, deductive methods,
task precedence graph (TPG), bottleneck processors,
%A David W. Walker
%A Geoffrey C. Fox
%A Gary R. Montry
%T The Flux-Corrected Transport Algorithm on the NCUBE Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1117-1126
%r cccp-495
%K applications in engineering, Kelvin-Helmholtz, VERTEX,
%A D. A. Weissbein
%A J. F. Mangus
%A M. W. George
%Z Northrup Aircraft
%T Solution of the 3-D Euler Equations for the Flow about a Fighter
Aircraft Configuration using a Hypercube Parallel Processor
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1127-1136
%K applications in engineering, FLO57, CFD, iPSC-MX, vector,
%A C. A. Addison
%A Jeremy M. Cook
%A L. R. Hagen
%Z Chr. Michelsen Inst., Bergen, Norway
%T An Interactive System for Seismic Velocity Analysis
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1138-1145
%K applications in geology, iPSC, normal movout (NMO) correction,
CDP (common depth point),
%A Lawrence J. Baker
%Z Exxon
%T Hypercube Performance for 2-D Seismic Finite Difference
Modeling
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1146-1156
%K applications in geology, ACOUS2D,
%A Robert W. Graves
%A Robert W. Clayton
%Z Seismo Lab, Caltech
%T Acoustic Wavefield Propagation using Paraxial Extrapolators
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1157-1175
%r cccp-613
%K applications in geology, finite element/difference,
%A Michael Gurnis
%A Arthur Raefsky
%A Gregory A. Lyzenga
%A Bradford H. Hagar
%Z Caltech
%T Finite Element Solution of Thermal Convection on a Hypercube
Concurrent Computer
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1176-1179
%r cccp-595
%K applications in geology,
%A Vijay K. Madisetti
%A David G. Messerschmitt
%Z UC Berkeley
%T Seismic Migration Algorithms on Parallel Computers
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1180-1186
%K applications in geology, sequential/parallel phase shift algorithm,
finite difference, PCP (parallel communication protocol),
%A Rosemary Renaut
%A Johnny Petersen
%Z Chr. Michelsen Inst., Bergen, Norway
%T Evaluation of a Vector Hypercube for Seismic Modelling
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1187-1192
%K applications in geology, iPSC-VX, acoustic wave equations,
finite difference,
%A John Salmon
%A Jeff Goldsmith
%Z Caltech
%T A Hypercube Ray-tracer
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1194-1206
%r cccp-592
%K applications in graphics, tiled decomposition, pipelining,
%A David Edward Orcutt
%Z U NV LV
%T Implementation of Ray Tracing on the Hypercube
[A Preliminary Report]
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1207-1210
%K applications in graphics, coordinate server, image collector,
node processes,
%A Laurence Boxer
%A Russ Miller
%T Dynamic Computational Geometry on Parallel Computers
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1212-1219
%K applications in mathematics, CREW PRAM, $lambda$ function,
convex hull, MIN,
%A Russ Miller
%A Quentin F. Stout
%T Computation Geometry on Hypercube Computers [Preliminary
Version]
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1220-1229
%K applications in mathematics, SCMD (single code multiple data),
dominates, fine and medium [MIMD] grain problems,
%A Barry A. Carpenter
%A Nathaniel J. Davis, IV
%Z AFIT
%T Implementation and Performance Analysis of Parallel Assignment
Algorithms on a Hybercube Computer
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1231-1235
%K military applications, BM/C↑3 (battle management/
command control and communication), iPSC, weapons to targets,
%A Charles W. Glover
%Z ORNL
%T Multi-Sensor Integration on the NCUBE Hypercube Computer
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1236-1246
%K military applications, MSI, data fusion, coarse grain distributed,
%A Thomas D. Gottschalk
%Z Caltech
%T Concurrent Multiple Target Tracking
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1247-1268
%r cccp-567
%K military applications, Mark III, Simulation 87, Kalman filtering,
BM (battle management/command, control, and communication,
ballistic missiles), CrOS, Crystal, decomposition, ticket, SDI,
defense,
%A Frederick Wieland
%A Lawrence Hawley
%A Abe Feinberg
%Z JPL
%T Implementing a Distributed Combat Simulation on the Time Warp
Operating System
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1269-1276
%r cccp-601
%K military applications, TWOS, Mark III, STB-87 simulation testbed,
concurrent theater level simulation (CTLS),
%A John Apostolakis
%A Clive Baillie
%A Hong-Qiang Ding
%A Jon Flower
%Z Caltech
%T Lattice Gauage Theory on the Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1278-1287
%r cccp-605
%K applications in physics, cosmic cube, monte carlo, NCUBE, Mark
IIIfp,
Fermions,
%A Clive F. Baillie
%A S. Lennart Johnsson
%A Luis Ortis
%A G. Stuart Pawley
%T QED on the Connection Machine
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1288-1295
%r cccp- 572
%K applications in physics, gauge theory, plaquette calculation,
quantum electro/chromo dynamics,
%A Sean Callahan
%Z Caltech
%T Non-Local Path Integral Monte Carlo on the Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1296-1302
%K applications in physics, CUBIX, NCUBE, comparisons to ELXSI and
Cray,
%A Paul A. Flinn
%Z Intel
%T Molecular Dynamics Simulation on an iPSC of Defects in Crystals
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1303-1312
%K applications in physics, iPSC, Hamiltonian, Rahman,
%A B. T. Werner
%A P. K. Haff
%T Dynamical Simulations of Granular Materials using the Caltech
Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1313-1318
%r cccp-612
%K applications in physics, packing, saltation,
%A Steven L. Groom
%A Meemong Lee
%A Alan S. Mazer
%A Winifred I. Williams
%Z JPL
%T Design and Implementation of a Concurrent Image Processing
Workstations Based on the Mark III Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1320-1321
%r cccp-599
%K applications in space science, elt (element processor),
CIPE (concurrent image processing element), CP, control processor,
%A J. S. Kim
%A G. C. Fox
%Z Caltech
%T The Prime Factor Non-Binary Discrete Fourier Transform and use of
the Crystal_Router as a General Purpose Communication Routine
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P1322-1327
%r cccp-523
%K applications in space science, PFA algorithm, DFT, cyclic
convolution,
Winograd algorithm (WFT), SAR (synthetic aperture radar),
%A Edward W. Felten
%A Steve W. Otto
%Z Caltech
%T Chess on a Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1329-1341
%r cccp-579
%K artificial intelligence, gaming, games, NCUBE, alpha beta pruning,
search, MIMD,
%A Les Gasser
%Z USC
%T Large-Scale Concurrent Computing in Artificial Intelligence
Research
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1342-1351
%K artificial intelligence, AI, multi-agent systems (MAS), reasoning,
distributed problem solving (DPS),
multi-agent computing environment (MACE),
intelligent coordinated system (ICE),
%A Gary B. Lamont
%A Donald J. Shakley
%Z AFIT
%T Parallel Expert System Search Techniques for a Real-Time
Application
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1352-1359
%K artificial intelligence, robotic air vehicle (RAV), military
application,
SDI, automated reasoning tool (ART), AI, iPSC, LISP, TI Explorer,
CCLISP, concurrent common LISP,
%A Keith Morgan
%Z GE ATL, Moorestown, NJ,
%T BLITZ: A Rule-Based System for Massively Parallel Architectures
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1360-1363
%K artificial intelligence, Connection Machine, MATCH-SELECT-EXECUTE,
matching, AI,
%A Stephen Taylor
%A Rony Shapiro
%A Ehud Shapiro
%Z Weizmann Inst.
%T FCP: A Summary of Performance Results
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1364-1373
%K artificial intelligence, flat concurrent prolog, systolic
programming,
dynamic management, matrix multiplication, merge sort, iPSC, FCPic,
stream producer/consumer, bounded buffers, incomplete messages, AI,
blackboards, short-circuit, OR-parallelism,
%A Robert J. Flynn
%A Haldun Hadimioglu
%Z Polytech U. of New York
%T A Distributed Hypercube File System
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1375-1381
%K databases and file systems, concurrent I/O (CIO), DB, FS, DFS,
concurrent file system (CFS), disk node (DN), processor node (PN),
%A John L. Pfaltz
%A Sang H. Son
%A James C. French
%Z U. VA.
%T ADAMS Interface Language
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1382-1389
%K databases and file systems, Advanced DAta Management system,
persistent identifiers, DB, FS, DFS,
%A Sang H. Son
%A John L. Pfaltz
%Z U. VA.
%T Reliability Mechanisms for ADAMS
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1390-1397
%K databases and file systems, Advanced DAta Management system,
checkpoints, concurrency control, LC, local clock, DB, FS, DFS,
ACPT/BCPT, after/before-checkpoint-transactions,
GCPN/LCPN, global/local checkpoint number, node recoverability,
%A Andrew Witkowski
%A Kumar Chandrakumar
%A Greg Macchio
%Z JPL
%T Concurrent I/O System for the Hypercube Multiprocessor
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1398-1407
%r cccp-611
%K databases and file systems, distributed file system,
multiprocessor,
cache consistency, synchronization, CIO, concurrent file systems
(CFS),
prefix table, file attributes, graphics application, disks, DB, FS,
DFS,
%A A. Kolawa
%A G. C. Fox
%Z Caltech
%T Use of the Hypercube for Symbolic Quantum Chromodynamics
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1408-1419
%r cccp-182C
%K databases and file systems, search, indexed database, Mark II, DB,
%A Ting-Wai Chiu
%Z Caltech
%T Shift-Register Sequence Random Number Generators on the
Hypercube Concurrent Computers
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1421-1429
%r cccp-526
%K basic algorithms, MIMD, CUBIX, Mark III, C language, bit
operations,
Kolmogorov-Smirnov test, auto-correlation,
%A Clare Y. Chu
%Z Northrup Aircraft, Hawthorne, CA
%T Comparison of Two-Dimensional FFT Methods on the Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1430-1437
%K basic algorithms, transpose-split (TS), vector-radix, iPSC,
local-distributed (LD),
%A David W. Walker
%Z Caltech
%T Portable Programming within a Message-Passing Model: the FFT as
an Example
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1438-1450
%r cccp-631
%K basic algorithms, fast Fourier transform, MIMD, VMLSCS
(virtual machine loosely synchronous communication system), VMP,
%A Xinming Lin
%A Tony F. Chan
%A Walter J. Karplus
%Z UCLA
%T The Fast Hartley Transform on the Hypercube Multiprocessors
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1451-1454
%K basic algorithms, FHT, FFT, fast Fourier transform,
%A William L. George
%Z Mich. Tech.
%T Binsorting on Hypercubes with d-Port Communication
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1455-1461
%K basic algorithms, sorting/searching, median, binsort 1, binsort 2,
%A Steven R. Seidel
%A William L. George
%Z Mich. Tech.
%T Binsorting on Hypercubes with d-Port Communication
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1455-1461
%K basic algorithms, sorting/searching, median, binsort 1, binsort 2,
%A D. C. S. Allison
%A Amal Chakraborty
%A Layne T. Watson
%Z YA Polytech.
%T Granularity Issues for Solving Polynomial Systems via Globally
Convergent Algorithm on a Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1463-1472
%K optimization and equation solving, iPSC, homotopy algorithm,
polynomial systems,
%A Craig B. Stunkel
%A Daniel A. Reed
%Z U. Ill.
%T Hypercube Implementation of the Simplex Algorithm
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1473-1482
%K optimization and equation solving, sparse matrix, iPSC,
linear optimization programming problem, row partitioning,
%A N. Toomarian
%Z ORNL
%T A Concurrent Neural Network Algorithm for the Traveling Salesman
Problem
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1483-1490
%K optimization and equation solving, TSP, LaGrangian multiplers,
%A Tarek S. Abdelrahman
%A Trevor N. Mudge
%Z U. MI
%T Parallel Branch and Bound Algorithms on Hypercube Multiprocessors
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1492-1499
%K branch and bound, BB, PBB, 0-1 integer linear programming (ILP),
NCUBE implementation, distributed, centralized lists,
%A Edward W. Felten
%Z Caltech
%T Best-First Branch and Bound on a Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1500-1505
%K branch and bound, traveling salesman problem (TSP), NCUBE,
queueing, memory usage,
%A Richard F. Ma
%A Fu-Sheng Tsung
%A Mae-Hwa Ma
%Z Aerospace Corp.
%T A Dynamic Load Balancer for a Parallel Branch and Bound Algorithm
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1505-1513
%K branch and bound, DLB, PBB, RS,
%A Roy P. Pargas
%A E. Daniels Wooster
%Z Clemson U.
%T Branch-and-Bound Algorithms on a Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1514-1519
%K branch and bound, Occam, FPS T-series,
%A Karsten Schwan
%A John Gawkowski
%A Ben Blake
%Z OSU
%T Process and Workload Migration for a Parallel Branch and Bound
Algorithm on a Hypercube Multiprocessor
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1520-1530
%K branch and bound, traveling sales person (TSP),
%A Christopher L. Cox
%Z Clemson U.
%T Implementation of a Divide and Conquer Cyclic Reduction
Algorithm on the FPS T-20 Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1532-1538
%K Tridiagonal matrix algorithms, memory access,
%A Omer Egecioglu
%A Cetin K. Koc
%A Alan J. Laub
%Z UCSB
%T Prefix Algorithms for Tridiagonal Systems on Hypercube
Multiprocessors
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1539-1545
%K Tridiagonal matrix algorithms, LU decomposition, MIMD, parallel
prefix,
%A Jay A. Jackson
%A Lorie M. Liebrock
%A Lynn R. Ziegler
%Z Mich. Tech. U.
%T A Hybrid Hypercube Algorithm for the Symmetric Tridiagonal
Eigenvalue Problem
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1546-1547
%K Tridiagonal matrix algorithms, FPS T-series, occam,
%X Very short poster paper.
%A V. A. F. Almeida
%A L. W. Dowdy
%A M. R. Leuze
%Z Vanderbilt U.
%T An Analytic Model for Parallel Gaussian Elimination on a Binary
C-Cube Architecture
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1550-1553
%K banded and full matrix algorithms,
%A Anne C. Elster
%A Anthony P. Reeves
%T Block-Matrix Operations using Orthogonal Trees
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1554-1561
%K banded and full matrix algorithms, vector matrix multiplication,
Gray codes, communication,
%A Judith D. Gardiner
%A Alan J. Laub
%Z UCSB
%T Solving the Algebraic Riccati Equation on a Hypercube
Multiprocessor
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1562-1568
%K banded and full matrix algorithms, pivoting, tridiagonalization,
parallel sign function,
%A A. Gerasoulis
%A N. Missirlis
%A I. Nelken
%A R. Peskin
%Z Rutgers
%T Implementing Gauss Jordan on a Hypercube Multicomputer
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1569-1576
%K banded and full matrix algorithms, NCUBE, GE, GJ, pivoting,
elimination,
%A G. A. Geist
%A R. C. Ward
%A G. J. Davis
%A R. E. Funderlic
%T Finding Eigenvalues and Eigenvectors of Unsymmetric Matrices using
a
Hypercube Multiprocessors
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1577-1582
%K banded and full matrix algorithms, QR algorithm, Hessenberg
reduction,
%A Chung-Ta King
%A Lionel M. Ni
%T Large-Grain Pipelining on Hypercube Multiprocessors
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1583-1591
%K banded and full matrix algorithms, matrix multiplication, NCUBE,
%A Charles S. Henkel
%A Michael T. Heath
%A Robert J. Plemmons
%T Cholesky Downdating on a Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1592-1598
%K banded and full matrix algorithms,
%A S. Lennart Johnsson
%A Ching-Tien Ho
%Z Yale
%T Expressing Boolean Cube Matrix Algorithm in Shared Memory
Primitives
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1599-1609
%K banded and full matrix algorithms, spanning binomial trees (SBT),
partitioning, matrix multiplication, Gray codes,
%A Alex Pothen
%A Padma Raghavan
%Z Penn. State
%T Distributed Orthogonal Factorization
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1610-1620
%K banded and full matrix algorithms, greedy Givens (ggs),
Householder,
%A Paul G. Hipes
%A Aron Kuppermann
%Z Caltech
%T Gauss-Jordan Inversion with Pivoting on the Caltech Mark II
Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1621-1634
%r cccp-578
%K banded and full matrix algorithms,
%A D. W. Walker
%A T. Aldcroft
%A A. Cisneros
%A G. C. Fox
%A W. Furmanski
%Z Caltech
%T LU Decomposition of Banded Matrices and the Solution of Linear
SYstems on Hypercubes
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1635-1655
%r cccp-582
%K banded and full matrix algorithms, ADI, pivoting,
%A Geoffrey C. Fox
%A Wojet Furmanski
%A David W. Walker
%Z Caltech
%T Optimal Matrix Algorithms on Homogeneous Hypercubes
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1656-1673
%r cccp-386B
%K banded and full matrix algorithms, Gaussian elimination, libraries,
decomposition, Jordan, inversion,
%A George Abe
%A Kunio Hane
%Z Keio U.
%T The Preconditioned Conjugate Gradient Method on the Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1676-1686
%K differential equations and associated matrix algorithms, hypercube,
concurrent processing, preconditioned conjugate gradient,
Poisson's solvers, load balancing, iPSC, BCG, SCG, CG, SOR, ICCG,
%A C. Aykanat
%A F. Ozguner
%A D. S. Scott
%T Implementation of the Conjugate Gradient Algorithm on a Vector
Hypercube Multiprocessor
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1687-1697
%K differential equations and associated matrix algorithms, iPSC-VX,
scaled CG (SCG),
%A Doug Baxter
%A Joel Saltz
%A Martin Schultz
%A Stan Eisenstat
%A Kay Crowley
%T An Experimental Study of Methods for Parallel Preconditioning
Krylov Methods
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1698-1711
%K differential equations and associated matrix algorithms,
%A Anjan Bose
%A Izzy Nelken
%A Jack Gelfand
%Z Sarnoff Res. Ctr., Princeton
%T A Comparison of Several Methods of Integrating Stiff Ordinary
Differential Equations on Parallel Architectures
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1712-1725
%K differential equations and associated matrix algorithms,
Gear integration, simulation,
%A Lisette de\ Pillis
%A Johnny Petersen
%A John de\ Pillis
%T An Iterative Solution to Special Linear Systems on a Vector
Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1717-1725
%K differential equations and associated matrix algorithms,
%A Paul Frederickson
%A Oliver A. McBryan
%T Intrinsically Parallel Multiscale Algorithms for Hypercubes
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1726-1734
%K differential equations and associated matrix algorithms, multigrid,
PSMG (parallel superconvergent multigrid),
%A M. Haghoo
%A W. Proskurowski
%Z Math. Dept., USC, LA
%T Parallel Implementation of Domain Decomposition Techniques on
Intel's Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1735-1745
%K differential equations and associated matrix algorithms,
%A E. N. Houstis
%A J. R. Rice
%A E. A. Vavalis
%Z Purdue U.
%T A Schwarz Splitting Variant of Cubic Spline Collocation
Methods for Elliptic PDEs
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1746-1754
%K differential equations and associated matrix algorithms,
%A Gregory A. Lyzenga
%A Arthur Raefsky
%A Bahram Nour-Omid
%T Implementing Finite Element Software on Hypercube Machines
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1755-1761
%r cccp-594
%K differential equations and associated matrix algorithms,
decomposition, solution,
%A Trond-Hemming Olesen
%A Johnny Petersen
%T Vectorized Dissection on the Hypercube
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1762-1786
%K differential equations and associated matrix algorithms, grids,
elimination, separators, balance,
%A Roy D. Williams
%Z Caltech
%T DIME: A Programming Environment for Unstructured Triangular Meshes
on a Distributed-Memory Parallel Processor
%J The 3rd Conference on Hypercube Concurrent Computers and
Applications
%V II, Applications
%I ACM
%C Pasadena, CA
%D January 1988
%P 1770-1787
%r cccp-502
%K differential equations and associated matrix algorithms,
distributed irregular mesh environment, boundary communications,
∂28-Nov-88 1051 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Tues Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 10:51:24 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 28 Nov 88 10:48:14-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA08840; Mon, 28 Nov 88 10:47:15 PDT
Date: Mon, 28 Nov 88 10:47:15 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8811281847.AA08840@Tenaya.stanford.edu>
To: faculty@score
Subject: Tues Lunch
Tomorrow, our faculty lunch guest will be Professor Charles Kruger,
Associate Dean for Academic Affairs of the School of Engineering.
Charles is a member of the Faculty Senate committee on the
professoriate and will be discussing the charge to that committee and
hearing our views on the matter. MJH 146, 12:15, November 29. -Nils
∂28-Nov-88 1103 hoffman@csli.Stanford.EDU the Symbolic Systems Forum Dec. 2
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 11:03:37 PST
Received: by csli.Stanford.EDU (4.0/4.7); Mon, 28 Nov 88 10:49:34 PST
Date: Mon 28 Nov 88 10:49:30-PST
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: the Symbolic Systems Forum Dec. 2
To: hoffman@csli.Stanford.EDU
Message-Id: <596746170.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
In The Symbolic Systems Forum for this week (Dec. 2), Lauri Karttunen will
speak on some of his work this summer. Professor Karttunen is very well
respected in his field and his project (as it relates to language and
information) falls within the central study of Symbolic Systems. As usual,
the Forum will be held at 3:15 in room 62n in building 60.
The languages of Tarski's World.
Lauri Karttunen
Xerox PARC / Department of Linguistics
Tarski's World is the logic teaching Macintosh game designed by Barwise and
Etchemendy. In this world, two languages are spoken: English and first
order logic. One of the objectives of the game is to teach how these
languages are related. The next version of the program will include a
translator that converts English sentences to logic formulas. My talk
will be about the design of the translator, the grammar or English and the
grammar of logic. How does one get from "every cube that is not flanked by
a tet is to the left of d" to "Ax ((cube(x) & ~Ey(tet(y) & flanks(y,x)))
--> left-of(x,d))"?
-------
∂28-Nov-88 1335 lansky@ai.sri.com REMINDER -- AIRR SEMINAR -- Tuesday 2pm -- Yoav Shoham
Received: from Warbucks.AI.SRI.COM by SAIL.Stanford.EDU with TCP; 28 Nov 88 13:35:51 PST
Received: from venice.ai.sri.com by Warbucks.AI.SRI.COM with INTERNET ;
Mon, 28 Nov 88 13:22:38 PST
Received: by venice.ai.sri.com (3.2/4.16)
id AA08812 for planlunch_reminder@ai.sri.com; Mon, 28 Nov 88 13:22:32 PST
Date: Mon 28 Nov 88 13:22:31-PST
From: LANSKY@Warbucks.AI.SRI.COM (Amy Lansky)
Subject: REMINDER -- AIRR SEMINAR -- Tuesday 2pm -- Yoav Shoham
To: planlunch_reminder@Warbucks.AI.SRI.COM
Message-Id: <596755351.0.LANSKY@VENICE.ARPA>
Mail-System-Version: <SUN-MM(229)+TOPSLIB(128)@VENICE.ARPA>
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
SOME LESSONS FROM NOTATIONAL ENGINEERING
Yoav Shoham (SHOHAM@SCORE.STANFORD.EDU)
Stanford University
2:00 PM, TUESDAY, November 29
SRI International, Building E, Room EJ228
Two instances are given where notational hacking has led to insight
into conceptual matters. In the first, we show how attempts to define
the concept of action in the context of temporal logics resulted in
identifying a close connection between action, knowledge and free
will. In the second, we show how attempts to combine the notions of
knowledge and belief in the same framework have resulted in a reversal
of a philosophical maxim: rather than view knowledge as an elevated
form of belief, we view belief as a defeasable form of knowledge.
This latter work was carried out jointly with Yoram Moses.
-------
∂28-Nov-88 1639 betsy@russell.Stanford.EDU Evening Seminar Meetings
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 16:39:06 PST
Received: by russell.Stanford.EDU (4.0/4.7); Mon, 28 Nov 88 16:40:58 PST
Date: Mon 28 Nov 88 16:40:57-PST
From: Betsy Macken <BETSY@CSLI.Stanford.EDU>
Subject: Evening Seminar Meetings
To: evesem@russell.Stanford.EDU
Cc: debra@russell.Stanford.EDU
Message-Id: <596767257.0.BETSY@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Emma has made a mailing list for the evening seminar attendees -- as you
see above.
Our next meeting will be 7 December at 7:30 -- note that we agreed to
change the time from 7 to 7:30.
We also agreed to change our meeting days from the first and third Wednesdays
of every month to the second and fourth Wednesdays of every month. Thus
in January, the meetings will be on the 11th and 25th.
Ivan Sag will be the speaker on 7 December, and Jon Barwise will be the
speaker on 11 January. I'll bring a sign-up sheet to the 7 December meeting
so please be thinking about what date would be best for you.
Betsy
-------
∂28-Nov-88 1653 nilsson@Tenaya.stanford.edu courses
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 16:53:23 PST
Received: from Tenaya.stanford.edu by russell.Stanford.EDU (4.0/4.7); Mon, 28 Nov 88 16:54:39 PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA09112; Mon, 28 Nov 88 16:50:19 PDT
Date: Mon, 28 Nov 88 16:50:19 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8811290050.AA09112@Tenaya.stanford.edu>
To: HELEN@CSLI.Stanford.EDU
Cc: ssp-faculty@russell.Stanford.EDU
In-Reply-To: Helen Nissenbaum's message of Tue 22 Nov 88 10:46:28-PST <596227588.0.HELEN@CSLI.Stanford.EDU>
Subject: courses
Answering your query about courses of possible interest to ssp
students:
We are planning to offer a course by Doug Lenat that will concentrate
on his research on large knowledge bases. You will have to get the
exact time,course number, units, title, etc. from Roy Jones (jones@score).
We may also offer a course by Stan Rosenschein on "Computer Agents."
If we do, we won't know the details for a couple of weeks.
-Nils
∂29-Nov-88 0847 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Proceedings of Concurrency '88
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 08:47:36 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA00577; Tue, 29 Nov 88 08:47:16 PDT
Message-Id: <8811291647.AA00577@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 29 Nov 88 08:47:10 PST
Received: by BYUADMIN (Mailer R2.01) id 0732; Tue, 29 Nov 88 09:45:37 MST
Date: Tue, 29 Nov 88 10:09:50 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Joe Halpern <HALPERN%ALMVMA.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Joe Halpern <HALPERN%ALMVMA.BITNET@forsythe.stanford.edu>
Subject: Proceedings of Concurrency '88
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
The proceedings of Concurrency 88 are now available in LNCS (#335)
from Springer Verlag for $35.
∂29-Nov-88 0925 aaai@sumex-aim.stanford.edu Trip Report to National Technological University
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 29 Nov 88 09:25:36 PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA18535; Tue, 29 Nov 88 09:23:33 PST
Date: Tue, 29 Nov 1988 9:23:32 PST
From: AAAI <aaai@sumex-aim.stanford.edu>
To: officers:;@sumex-aim.stanford.edu
Cc: aaai@sumex-aim.stanford.edu
Subject: Trip Report to National Technological University
Message-Id: <CMM.0.88.596827412.aaai@sumex-aim.stanford.edu>
Monday, November 21, 1988
Visit to National Technological University, Ft. Collins, Co.
On the above date, I visited with Dr. Lionel Baldwin, President of NTU, and
Richard Soderberg, Director of NTU Professional Development Programs. The
purpose of my visit was to review their facilities, discuss their organization-
al, marketing and sales structures, and review possible financial arrangements
for the satellite transmitted tutorials as professional development courses.
NTU is a program with the Association for Media-based Continuing Education for
Engineers (AMCEE). Incorporated in 1985, the association divided its credit
versus non-credit courses between NTU and a group in Georgia. In 1987,
NTU assumed the responsibilities of both credit and non-credit programs.
NTU is a non-profit organization identified under the IRS code 501 (c) (3)
and 509 (a) (1). NTU has a staff of 20 people. They have studio sites
in about 7 locals across the country.
FINANCIAL STRUCTURE
NTU provides courses to over 230 different sponsoring corporate sites and
25 member universities. Each sponsoring site pays an annual fee to NTU to
use their satellite network. In addition to the annual fee, each sponsoring
site will pay a regisitration fee for each course. Usually the registration
fee is based on a graduated scale beginning with approximately $200 a person
for a full day course (4 1/2 hours of lecture) up to 6 attendees.
After 6 registrants, it is $1250 per course per site. Each course collects
$36-42,000 gross revenue per tutorial.
The typical financial arrangement with NTU and outside organization follows:
* NTU receives 40% gross revenues; they are responsible for all
marketing and sales; invoicing of the sites, transponder time
for the broadcast, accounts receivable collection and distribution
of funds.
* Organization receives 60% gross revenues; they are responsible
for the selection of the tutorial, payment to the speakers,
studio and uplink facility and costs to the mailing of the
tutorial syllabi to the sites.
We could expect between $10-16,000 net revenues per tutorial. Presently
we net about $27,000 per tutorial.
In addition after a review of their 1987-1988 Annual Report, NTU is barely
breaking even with their expenses outweighting their revenues in 1987-88.
They have a sizeable accounts receivables with their investment in the
physical facilities as their primary assets. I have a copy of the
report in my office if you would like to review it.
Marketing/Sales Efforts
NTU uses each site's coordinator as the primary mechanisms to distribute
their promotional literature about each quarter's course offerings. Each
month NTU mails to 12,000 names their course offering catalogue and updates.
They do no display advertising, but sponsor a free week long management
seminar to find new students and site sponsors. They feel that live
presentations is the best demonstration of the network's capabilities
and the best form of advertising.
For their professional development courses, they do no marketing
research to determine what courses their sites sponsors want to attend.
Their approach is to simply send a list of prospective course outlines
to their site sponsor's coordinators and ask them to see if anyone in
their organization is interested in these courses. This is clearly the
weak link in their advertising efforts.
They do very little evaluation of their courses to determine the
adequacy of their speakers and course content.
They limit their sales efforts to the domestic marketplace and have not
begun to explore any foreign network distribution of their professional
development courses.
OPERATIONS
The AAAI would be responsible in preparing a first draft of course
selections. NTU would then distribute that list to their site sponsor's
coordinator and get their feedback. After a determination of final
course offerings was made, then we would create our own speaker
fee contract and set up a schedule with NTU and the speaker.(They have already
suggested four tutorials for 1989). The speaker would then go to one of the
studio sites and simply give his lecture as if he or she was in a
classroom.
IEEE AND ACS
At this time only IEEE produces courses on this network. However they
do their own advertising, studio broadcasting, etc (the works!), and
they apparently lose money. IEEE only uses the satellite network and
some advertising organs of NTU. ACS is still formulating its program
and hopefully it will be implemented in 1989.
TRENDS
There is a growing trend for large corporations to establish their own
satellite networks (ie IBM, HP) and offer their own classes.
NTU is linking into these networks at this time.
The motivation for the establishment of these private networks
is to cut the costs of corporate educational efforts by offering
courses. Presently, it costs a corporation $350 per day to send
someone to an off-site class while an internal class is $150 per day.
At some point the growth of alternative delivery methods
of educational offerings will eat into our tutorial revenues. At
this time, there is no evidence that our tutorial revenues are
dropping.
COMMENTS
Clearly, NTU is a young organization, struggling financially at this time,
with a weak marketing and sales structure.
However, if the trend for more internal-derived technical and professional
courses continues, then NTU may be in a very advantageous position in the
future. If AAAI was to establish its own satellite tutorials, then we would
already be in the position to take advantage of any changes in trends.
If the Council were to decide on working with NTU, then we should proceed
slowly and carefully by ensuring that our tutorial revenues are not
cut by our own satellite sponsored tutorials. We may be able to achieve
this by scheduling courses on the satellite network that do not conflict
with our ongoing conference tutorial program.
I would like your comments on the proposal to establish satellite
tutorials. If you need any additional information about NTU, please
send me a message.
Claudia Mazzetti
∂29-Nov-88 0949 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu EUROCRYPT '89: final call for papers
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 09:49:29 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA04178; Tue, 29 Nov 88 09:49:02 PDT
Message-Id: <8811291749.AA04178@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 29 Nov 88 09:48:56 PST
Received: by BYUADMIN (Mailer R2.01) id 2479; Tue, 29 Nov 88 10:47:23 MST
Date: Tue, 29 Nov 88 10:11:31 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Jean-Jac. Quisquater" <jjq%prlb2.uucp%BLEKUL60.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Jean-Jac. Quisquater" <jjq%prlb2.uucp%BLEKUL60.BITNET@forsythe.stanford.edu>
Subject: EUROCRYPT '89: final call for papers
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
FINAL CALL FOR PAPERS
EUROCRYPT '89
April 10-13, 1989
Houthalen, BELGIUM
A WORKSHOP ON THE THEORY AND APPLICATIONS OF CRYPTOGRAPHIC TECHNIQUES
An international conference sponsored by the
International Association for Cryptologic Research (IACR)
Organizing Committee
Joos Vandewalle (General chairman)
Tri An Banh (ULg, Li`ege)
Marijke De Soete (RUG, Gent)
Jean Doyen (ULB, Bruxelles)
Jean-Marie Goethals (UCL, Louvain-la-Neuve)
Ren'e Govaerts (KUL, Leuven)
Emile Peeters (CEC, Brussels)
Jean Ramaekers (FUN, Namur)
Bart Preneel (Local arrangement)
Program committee
Jean-Jacques Quisquater (Program chairman)
Paul Camion (INRIA, Rocquencourt)
Yvo Desmedt (UW, Milwaukee)
Louis Guillou (CCETT, Rennes)
Johan H\astad (RIT, Stockholm)
Lloren\c Huguet (UAB, Barcelona)
Wyn Price (NPL, Teddington)
Rainer Rueppel (Crypto AG, Steinhausen)
Johan van Tilburg (PTT-DNL, Leidschendam)
The conference deals with all aspects of the theory and the application of
cryptography including symmetric and asymmetric ciphers, authentication,
protocols, secure transactions, signatures, sequences and linear complexity,
hardware and software topics, security of telecommunication systems and
computer networks.
The meeting will be held in the calm, spacious and relaxing atmosphere of
the Conference Centre Hengelhoef, 80 km east of Brussels or Antwerp near
exit 30 of the E314 freeway.
Original papers are invited on all topics related to the current work in the
theory and application of cryptographic techniques. Propositions for long
overviews are welcome. Send 6 copies of abstract before January 9, 1989, to:
Dr. J.-J. Quisquater, Program Chairman
Philips Research Laboratory tel.: +32-2-674 22 43
Avenue Van Becelaere, 2 telefax: +32-2-674 22 99
B-1170 Brussels, Belgium email: eurocrypt@prlb2.uucp
Abstracts should provide sufficient details (about 4 pages) to allow program
committee to assess the merit of the final paper. Authors will be notified
by February 15, 1989 about the acceptability of their papers. It is
anticipated that complete conference proceedings will be published.
A rump session and a session about open problems will be
organized
during the conference.
More details of the program and a registration form will be sent in January
to all attendees of previous Crypto or Eurocrypt Conferences, and to everybody
receiving this call by mail. To make certain that you are on the mailing list
send the following request for information to:
Prof. J. Vandewalle, General chairman
ESAT Katholieke Universiteit Leuven tel.: +32-16-22 09 31
Kard. Mercierlaan, telex: 25941 elekul
B-3030 Heverlee, Belgium telefax: +32-16-22 18 55
email: eurocrypt@kulesat.uucp
Name ______________________________ Affiliation: _______________________________
Street _________________________________________________________________________
City __________________________ State: _____________________Zip: ______________
Possible submission of a paper: (YES) (NO)
Participation: (YES) (NO)
∂29-Nov-88 1004 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu 3rd Symposium on Complexity of Approximately Solved Problems --
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:04:27 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA05155; Tue, 29 Nov 88 10:04:05 PDT
Message-Id: <8811291804.AA05155@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 29 Nov 88 10:03:58 PST
Received: by BYUADMIN (Mailer R2.01) id 2812; Tue, 29 Nov 88 11:02:25 MST
Date: Tue, 29 Nov 88 10:04:42 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Kerny McLaughlin <kerny%CS.COLUMBIA.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Kerny McLaughlin <kerny%CS.COLUMBIA.EDU@Forsythe.Stanford.EDU>
Subject: 3rd Symposium on Complexity of Approximately Solved Problems --
Call fo
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
CALL FOR PAPERS
Third Symposium on Complexity of Approximately Solved Problems
April 3-5, 1989
PROGRAM COMMITTEE:
Kenneth Arrow
Department of Economics
Stanford University
Stanford, California
Jerome Feldman
International Computer Science Institute
147 Center Street
Berkeley, California
Richard Karp
Computer Science Department
University of California at Berkeley
Berkeley, California
Christos Papadimitriou
Computer Science Department
University of California at San Diego
San Diego, California
Steven Smale
Mathematics Department
University of California at Berkeley
Berkeley, California
Joseph Traub
Computer Science Department
Columbia University
New York, New York
Henryk Wozniakowski
Computer Science Department
Columbia University
New York, New York
Donald Ylvisaker
Statistics Department
University of California at Los Angeles
Los Angeles, California
SOME OF THE TOPICS TO BE ADDRESSED ARE:
Average Case Analysis of Algorithms Neural Nets
Computational Complexity Optimal Recovery
Computer Vision Parallel Computation
Connectionist Models Prediction and Estimation
Continuous Complexity Random Algorithms
Decision Theory Random Complexity
Design of Experiment Robotics
Distributed Complexity Scientific Computation
Information-Based Complexity Seismology
Inverse Problems Signal Processing
Mathematical Economics
INVITED SPEAKERS: Invitations have been sent to the invited speakers.
A list of invited speakers will be posted in one to two months.
CONTRIBUTED PAPERS: All appropriate papers for which abstracts are
contributed will be scheduled. Contributed papers will be twenty
minutes in length. This is the same length as invited papers.
Contributed papers will be presented in parallel sessions.
To contribute a paper send title, author, affiliation, and abstract on
a single 8 1/2 by 11 sheet of paper or by electronic mail.
The above can be sent by U.S. mail or electronic mail to:
J.F. Traub
Computer Science Department
Columbia University
450 Computer Science Building
New York, New York 10027
Electronic Mail: kerny@cs.columbia.edu
TITLES AND ABSTRACTS MUST BE RECEIVED BY NO LATER THAN FEBRUARY 1, 1989
PUBLICATION: Invited papers will be published in the Journal of Complexity.
REGISTRATION: The symposium will be held in the Kellogg Conference
Center, on the fifteenth floor of the International Affairs Building,
Columbia University, 118th Street and Amsterdam Avenue. Registration
will start at 9:00 a.m. THERE IS NO REGISTRATION CHARGE.
FOR FURTHER INFORMATION: The program schedule will be sent
electronically about March 1, 1989. If you have any questions,
contact Kerny McLaughlin, Computer Science Department, Columbia
University, (212) 854-2736.
To help us plan the symposium please complete the information
below and return by U.S. Mail to Traub or by electronic mail to
kerny@cs.columbia.edu.
-------------------------------------------
SYMPOSIUM ON COMPLEXITY OF APPROXIMATELY SOLVED PROBLEMS
April 3-5, 1989
Name:
Affiliation:
Address:
[ ] I will attend the Complexity Symposium.
[ ] I may attend the Complexity Symposium.
[ ] I will contribute a paper.
∂29-Nov-88 1005 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Just a reminder....
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:05:49 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 29 Nov 88 10:01:28-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA05055; Tue, 29 Nov 88 10:02:24 PDT
Date: Tue, 29 Nov 1988 10:02:22 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score
Subject: Just a reminder....
Message-Id: <CMM.0.87.596829742.chandler@polya.stanford.edu>
The SOE Annual Faculty Report for Academic Year 1988-89 is due in my office
on 12/1.
∂29-Nov-88 1007 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu More Responses to query by Yelland
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:06:59 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA05353; Tue, 29 Nov 88 10:06:30 PDT
Message-Id: <8811291806.AA05353@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 29 Nov 88 10:06:23 PST
Received: by BYUADMIN (Mailer R2.01) id 2864; Tue, 29 Nov 88 11:03:09 MST
Date: Tue, 29 Nov 88 10:13:25 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: "Victor Miller -- moderator, Theory Net" <THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu>
Subject: More Responses to query by Yelland
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Her are some more responses to the query by Phillip Yelland:
------------------
Date: 22 Nov 88 18:47:52 GMT
From: tank!tartarus.uchicago.edu!simon@handies.ucar.edu (Janos Simon)
Organization: U. Chicago Computer Science Dept.
Subject: Re: Drawing sets
Look at the last CACM. There is a paper by Rubinstein, Shallit and Szegedy
that is relevant.
------------------------------------------------------------------------
Date: 22 Nov 88 18:38:52 GMT
From: Krulwich-Bruce@yale-bulldog.arpa (Bruce Krulwich)
Organization: Computer Science, Yale University, New Haven, CT 06520-2158
Subject: Re: Drawing sets
In article <23601@amdcad.AMD.COM>, prem@crackle (Prem Sobel) writes:
>pmcy@cl.cam.ac.uk (Phillip Yelland) writes:
>>I am given a collection of (non-disjoint) sets. The task is to represent
>>these sets as rectangles on a plane, with rectangles over-lapping where the
>>intersections between their corresponding sets are non-empty (or, indeed, to
>>establish that such a drawing is impossible). So for example, given:
>>...
>
>Also, as stated the problem is actually unsolvable in the general case.
>The statement of the problem requiring either rectangular regions or a
>planar solution will make it impossible to solve as stated. As a
>counter example, take the sets:
> A = {1,2,4,5,8}
> B = {1,2,3,6,8}
> C = {1,3,4,7,8}
>Except for region 8, this is a description of all possible overlap of 3
>sets:
> *--A--*
> | |
> | 5 *-+---*
> | |2| 6 |
> | *-+-+-* |
> | |4|1| | B
> *-+-+-+ | |
> | | 3| |
> | *---+-*
> | 7 |
> *-C---*
>topologically, the only way to include region 8 is to "bend" or imbed the
>3 rectangles on the surface of a sphere and have them overlap in region 8
>on the "other hemisphere" from region 1.
I don't think that the problem as stated above disallowed putting the 8 in
the same region as the 1. The problem is to have an overlapping region for
everywhere where the intersection of the relevant sets is nonempty.
Bruce Krulwich
------------------------------------------------------------------------
Date: 22 Nov 88 15:43:47 GMT
From: polyof!kepler1!rjfrey@nyu.edu (Robert J Frey)
Organization: Kepler Financial Mgmt, Setauket, NY
Subject: Re: Drawing sets
In article <100600008@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes:
> For a given number of sets and intersections, construct a graph
> with one vertex per set, and an edge for each intersection...
I'm not sure this would work, since there is not a 1:1 correspondence
between the simple pairwise intersections of the sets and the "overlaps"
which must exist in the drawn representation. Consider the set {{3,4,5,7,11,
12},{5,6,7,8,9},{10,12,13,9},{1,2,3,4,5}}. This results in a K4 graph with
edges modeling pairwise intersections. There must be an overlap region {4},
which is not provided for in your agorithm.
Let A be a set of elements, and P be a set of subsets of A. Let S be the
power set of P, ie, the set of all subsets of P. Let V be a set of subsets
of A such that v is an element of V if and only if it is equal to a nontrivial
intersection of the elements of S. The set V is the overlap set for P.
Form a graph G=(V,E) where two elements of V are adjacent iff there is a
nontrivial intersection between them. If this graph is not planar, then
you're out of luck. If it is planar, then take its dual graph, giving the
required representation, although not necessarily rectangular.
Yor basic idea was correct, but you must model all n-wise intersections and
not just pairwise intersections (unfortunately).
------------------------------------------------------------------------------
|Dr. Robert J. Frey | {icus, spl1, dasys1}!acsm!kepler1!rjfrey |
|Kepler Financial Management, Ltd.|------------------------------------------|
|100 North Country Rd., Bldg. B | The views expressed are wholly my own and|
|Setauket, NY 11766 | and do not reflect those of the Indepen- |
|(516) 689-6300 x.16 | dent Republic of Latvia. |
------------------------------------------------------------------------------
Date: 22 Nov 88 17:52:12 GMT
From: attcan!utgpu!jarvis.csri.toronto.edu!neat.ai.toronto.edu!sjb@uunet.uu.net
Organization: Department of Computer Science, University of Toronto
Subject: Re: Drawing sets
In article <23601@amdcad.AMD.COM> prem@crackle.AMD.COM (Prem Sobel) writes:
>In article <382@scaup.cl.cam.ac.uk> pmcy@cl.cam.ac.uk (Phillip Yelland) writes:
>>I am given a collection of (non-disjoint) sets. The task is to represent
>>these sets as rectangles on a plane, with rectangles over-lapping where the
>>intersections between their corresponding sets are non-empty (or, indeed, to
>>establish that such a drawing is impossible).
>
>The good news, is that I have developed a means to solve the cases that
>are representable. I worked this out as a cover reduction algorithm for
>Boolean equations. This algorithm, will always give a solution but it
>will be yield hypercubes in 'N' dimensional Euclidean space.
>
Can you find the least N such that the system has a representation as an
embedding of N-dimensional cubes in N-dimensional space? That would be
extremely interesting. For a given N, what systems have representations as
embeddings in N-space? Relatively little seems to be known about this
area.
A result here might shed light on the following conjecture:
If G is a bipartite graph with boxicity K, then G has gridicity K-1.
Here, the boxicity of G is the least dimension k such that G can be
represented by the embedding of k-dimensional rectangles in k-space. The
gridicity of G is the least dimension k such that G can be represented
by the embedding of k-dimensional rectangles in k+1 space (the rectangles
must be aligned on coordinate axes). The conjecture has been proved for k=2.
:stephen
sjb@ai.toronto.edu, sjb@\[128.100.1.65\]
Department of Computer Science
University of Toronto
Toronto, ON, Canada M5S-1A4
∂29-Nov-88 1054 SLOAN@Score.Stanford.EDU ["Karen Bennett" <NA.KXB@Forsythe.Stanford.EDU>: Employee ID card -- minor typographical error]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:54:36 PST
Date: Tue 29 Nov 88 10:49:53-PST
From: Yvette Sloan <SLOAN@Score.Stanford.EDU>
Subject: ["Karen Bennett" <NA.KXB@Forsythe.Stanford.EDU>: Employee ID card -- minor typographical error]
To: Staff@Score.Stanford.EDU, Faculty@Score.Stanford.EDU
Message-ID: <12450472826.17.SLOAN@Score.Stanford.EDU>
Return-Path: <NA.KXB@Forsythe.Stanford.EDU>
Received: from forsythe.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 29 Nov 88 09:51:05-PST
Date: Tue, 29 Nov 88 09:51:49 PST
To: sloan@score
From: "Karen Bennett" <NA.KXB@Forsythe.Stanford.EDU>
Subject: Employee ID card -- minor typographical error
To: PETERSON@SIERRA, SLOAN@SCORE, ND.SMS
FORWARDED MESSAGE 11/28/88 15:03 FROM NA.KMD "Kathy Davis": Employee ID card --
minor typographical error
To: NA.KXB
FORWARDED MESSAGE 11/28/88 10:59 FROM AT.PLC "PCURRY (3-0730)": Employee ID
card -- minor typographical error
Dear Staff Affairs Officers:
There is a typographical error in the employee ID cards that are
being distributed currently through Campus Mail. The words
"employee's signature," which have been on the card for years, were
inadvertently replaced this year by the words, "employer's
signature." I regret the error, apologize for its occurrence, and
would appreciate your help in fielding questions about it.
The typo is not material and therefore does not warrant a recall of
cards already issued. We are not issuing a broadcast memo to
department administrators on this subject. You are welcome to
forward or otherwise use this note as you think appropriate in your
area. If you get questions, please explain that people can change
the cards themselves, and that while it is a nuisance, it is not a
serious problem.
ID cards issued after December 1 will have the correct text.
Additional questions? Call or refer to 3-9182. Thanks.
Philip Curry
Personnel Services
To: HRG&S(RR.LED,HK.RBP,HK.PEF,HK.MHH,HK.LWP,HF.KXG,CT.KIS,CR.TDK,CR.PLH,
AU.ADW,AT.MCM,DUPEN@SLACVM), SAOS(RR.LED,RQ.HXC,RG.FIN,PA.ZYK,NA.KMD,
MA.LSL,KA.KFW,HK.MHH,HK.JFA,HK.IRC,HK.ARG,HF.PMC,HF.KXG,GD.DAS,GD.CLB,
EA.YSK,EA.LLS,CT.SIS,CT.KIS,CR.TDK,CR.PLH,CR.JKW,CR.BAH,CN.LPO,CA.AWY,
AU.A14,AU.ADW,AR.CBJ,AK.ROB,AK.MDD,S.NORMA@GSB-WHY,RUTH@EREBUS,
REG@JESSICA,DUPEN@SLACVM,BL.LXR@RLG), PERS(HK.PEF,AT.ROS,AT.PLS,AT.MCM,
AT.KWC,AT.JXM,AT.JGW,AT.EPB,AT.CLD)
FORWARDED ON 11/29/88 09:49 FROM NA.KXB "Karen Bennett": Employee ID card --
minor typographical error
To: NG.RLB, HF.JJC, DEWERK@SCORE, DIETRICH@SIERRA, DISKIN@KRAKATOA, NA.RXE,
FLORENCE@SCORE, GERLACH@SIERRA, SCHANSEN@SIERRA, NA.RXH, KELVIE@SIERRA,
DESIGN@SIERRA
-------
∂29-Nov-88 1139 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Colouring a graph in polynomial time
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 11:39:16 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA13032; Tue, 29 Nov 88 11:38:30 PDT
Message-Id: <8811291938.AA13032@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 29 Nov 88 11:38:22 PST
Received: by BYUADMIN (Mailer R2.01) id 4432; Tue, 29 Nov 88 12:36:29 MST
Date: Tue, 29 Nov 88 13:24:51 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Roger Oscarsson <roger%CS.UMU.SE@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Roger Oscarsson <roger%CS.UMU.SE@Forsythe.Stanford.EDU>
Subject: Colouring a graph in polynomial time
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
I have developed an algorithm which colours an arbitary graph in polynomial
time. As this is a NP-complete problem I have reasons to believe the
algorithm being faulty. I have not proven this algorithm to be correct
(surprise, surprise!), but neither have I proven it to be incorrect. Being
a computer scientist and not a graph theorist I am more into empirical
methods. I have tried it on several graphs and so far it has always managed to
I don't want to publish this algorithm before I can prove it to be correct,
or atleast tried it on numerous cases. I would really appreciate if someone
could send me some nasty graphs to colour, preferably some (all?) of the tests
used in the proof of the four-colouring problem.
AtDhVnAnNkCsE
P.S. I have a friend who is interested in maximal matchings and the vertex-
covering set. Please also send me any information you have on algorithms for
these problems so I can forward it to him.
---
Roger Oscarsson Internet: roger@cs.umu.se
Inst. of Info. Proc Uucp: ...!mcvax!enea!cs.umu.se!roger
Umea University
S-90187 Umea, Sweden
∂29-Nov-88 1235 X3J13-mailer ISO Meeting Report
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Fellow Colleagues:
The following is my report on the November ISO meeting. I am sending
this now for several reasons. First, because it is fresh in my mind.
Second, because the events are a little more dramatic than usual.
Third, because one outcome was the cancellation of the January ISO
meeting in Hawaii.
The US Delegation consisted of Bob Mathis, Thom Linden, Patrick
Dussud, Gregor Kiczales, and myself. The meeting was held at the
Building of the European Community in Brussels, Belgium. It was held
Monday and Tuesday, November 21 and 22.
Attending were France, The Netherlands, Germany, Japan, the UK, and
the US.
The US presented its position statement, which is as follows:
************************************************************************
The US is currently undertaking two standardization efforts in Lisp:
X3J13 is standardizing Common Lisp for ANSI, and IEEE is standardizing
Scheme. The US believes that these two efforts cover a wide range of
concerns and uses for Lisp: Scheme is small, elegant, and
mathematically well-founded, and Common Lisp is full-featured, mature,
and commercially viable. Within the United States, there is no demand
for another Lisp standard at this time.
The current activity of WG16 is to develop a standard for a dialect of
Lisp directed at a community of users who are served neither by Common
Lisp nor by Scheme---that dialect is IsLisp. Although is is unlikely
that IsLisp will have major near term commercial significance within
the US, the US supports the IsLisp standardization effort as long as
it does not negatively affect standards for other dialects of Lisp.
In particular, the US feels that it is important not to have two
standardized dialects of Lisp that are nearly identical unless one is
a strict subset of the other. Having two such similar but different
dialects weakens the position of users who have come to depend on one
of the dialects.
The US believes that the primary focus of standardization is to codify
existing practice to support the creation and delivery of portable
software. Thus, the major focus of the US standardization efforts is
to provide stability to the community of Common Lisp and Scheme users.
Of secondary importance are the invention of new Lisp dialects and the
standardization of Lisp dialects or features not in common usage. The
US therefore agrees with the ISO goal of a near term standard in the
1990 time frame along with longer range consideration of future
dialects and features.
Common Lisp is in wide use in Europe, Japan, and Australia.
Implementations of Common Lisp are under way in the UK, Germany,
Italy, and Japan (and possibly other countries). In each of these
countries there are companies whose customers depend on portable
software written in Common Lisp. The future of these companies thus
depends on having a Common Lisp standard.
The US believes that Common Lisp is a valid candidate for
international standardization both because it is used internationally
and also because it is a mature and stable dialect. Common Lisp has
been under design and specification for 8 years. Commercial quality
implementations of Common Lisp have been available for 4 years. The
near term standardization of ISO Common Lisp would have substantial
positive impact on the acceptance of existing commercial Lisp
implementations and on the viability of future Lisp dialects as
vehicles for emerging applications.
For these reasons, the US proposes the development of an ISO standard
for Common Lisp. Furthermore, the US proposes that WG16 request X3J13
to prepare the ISO draft standard for Common Lisp. The ISO Common
Lisp draft and the ANSI Common Lisp draft should be identical. The US
believes such a draft standard could be developed by December 1989.
The US also believes the development of an ISO standard for Common
Lisp is within the charter of WG16, which endorses the standardization
of multiple dialects of Lisp. At some point in the future, it may be
appropriate to develop an ISO standard for Scheme.
Looking beyond near term standardization, the US feels that an
important task for WG16 is working towards a next generation dialect
of Lisp, and this can be accomplished by drawing on the lessons
learned from existing dialects of Lisp.
************************************************************************
In addition, we proposed the following resolution:
************************************************************************
The U.S. proposes the following ISO WG16 resolution:
It is important to affirm and strengthen the position of the
international community of users who depend on Common Lisp. It is
also imperative that an international standard for Common Lisp must be
subject to international review and revision.
ISO WG16 resolves to proceed with an ISO Common Lisp standardization
process in the following manner:
* WG16 requests X3J13 to produce an ISO draft standard for Common
Lisp in accordance with SC22 synchronization principles for national
body development.
* The X3J13 drafting procedure will accommodate international public
review as well as U.S. public review. X3J13 will establish a schedule
to allow processing of all public comments.
* The timetable for forwarding a draft for circulation by WG16 is
December 1989. The U.S. should make every effort to meet this
schedule.
* X3J13 will inform WG16 of its schedules and progress.
************************************************************************
The German Delegation also had a written position statement. It is as
follows:
************************************************************************
The Position of DIN concerning LISP standardization
Herbert Stoyan
University of Konstanz
November 18, 1988
1. Our Goals
When the LISP-standardization process started we were optimistic to reach a
quick result. Now we have to change our feeling. It will take longer than we
have imagined. To speed up the process we want to change some of our position
statements made in Paris.
First, we voted for CommonLISP as a starting point for standardization. We
want to change this commitment into an open one. We join the US that one of
Scheme or CommonLISP (but not both) should be used.
Second, we made a vote for desirable characteristics of the standard. We
regret that not all points went as we desired. But the issues seem to be
mixed: There are language issues and report issues.
Before all the points, we should all agree that standardization is only
partially a language definition activity. We should standardize an existing
language. Therefore we don't like anymore the list of default values for
language components. If we still intend to follow this direction we get
everything but a language which is usable. We don't feel that this was a good
idea. DIN will accept any proposal for a LISP standard and check every part
of it - not only functional objects etc.
Obviously, the goal of standardization is portability. Therefore this issue
deserves most attention. We got here the right mark. The next issue of
standardization seems to be processor conformity. We would like to change our
figure `6' into a `2'. We believe the conformity must be provable: Without a
proof procedure for conformity our work is not complete. Especially, there
has to be a test suite.
The standard report must be technical clear. Therefore a clear semantics is
important. It is the way to achieve portability. We ranked this topic with
`3' and support this vote again. The standard report has to be
understandable. An important means to achieve this is a simple semantics. We
miss understandability as characteristics and again want to stress our figure
`4' here.
A standard report has to be usable. That means, it should be well organized,
it should not be too voluminous, it should be use not too many references to
other parts. Maybe this was meant by `Ease of learning'. We believe that
this characteristic is only an indicator for this quality of the standard.
Therefore we want to change our figure of `12' into a `5'.
Now, concerning the language. A language to be standardized must be
interesting. That must be already - we cannot change it. May be this is what
was meant as `Power'. We want to rank this point at first place in the
language goals we have. Power does not mean to provide everything. A
language which is too large and complex has no power and will not be
appealing. History of programming languages proves that baroque languages
will not last for long. Therefore we want to vote for `Compactness' - but it
is not in the list of characteristics.
If a language is big only because of many concepts which enable variations of
expressions for one and the same thing then the language is defined badly. If
the language contains elements which cannot be combined it should be regarded
as a family of languages. Both dimensions are called orthogonality. We want
to vote for `Orthogonality' - but cannot find it.
There are characteristics of implementations. Issues like efficiency,
consistency interpreter/compiler, stability etc. come in mind. They are goals
for implementors. Good implementors will achieve them - bad implementors wil
fail. These are not goals of standardization.
Ease of implementation is a goal which is always fulfilled with LISP. The art
is to find a way to quality.
2. The Situation
Our original proposal was to standardize a kernel of LISP with parts everybody
will accept readily. This work could be done in 18 month. But there are not
many countries to support this approach.
Richard Gabriel made the point that three languages should not be
standardized. We adopt this position. We have to ask who moved us in the
position where this danger is to be faced. Obviously, it is the pair of
US-activities. It was clear to ANSI that CommonLISP is not ready for
standardization. A de-facto standard ist not a true standard. We want not
decide without studying the latest draft of CommonLISP if it achieved enough
quality. Furthermore, we have the feeling that the activity for standardizing
Scheme was started to contravene the European desire for a clean LISP kernel.
3. Our Proposal
ISO is not an organisation for creating new languages. The maximal thing we
should plan is to change a presented language somewhat. The French have
exposed the three level approach. There seems nobody (with exception of DIN)
who likes the idea.
Therefore: We propose to take the draft reports of CommonLISP and Scheme
and check them for quality of being standardized. If they both have the
quality, we should standardize both of them with ISO. If only one has
the quality we should take this one. If none of the has the quality we
should generate a list of required changes and wait for better drafts. In the
meantime other member bodies are invited to define LISPs which deserve
standardization.
************************************************************************
In summary, they commented that the current ISO process does not seem
to be converging on a standard quickly enough, and that a short-term
standard can produced only by working with an existing dialect and
draft. They proposed that drafts for X3J13 Common Lisp and IEEE Scheme
be considered and measured against several criteria. These are that
the draft be clear and unambiguous, not unacceptably long (< 300 pages
was suggested), and precisely stated. The languages ought to be as
crisp and orthogonal as possible (that is, minimal redundant
features). The German Delegation proper consisted of Klaus Daessler
(Siemens), Dieter Kolb (Siemens), and Herbert Stoyan (University of
Konstanz). Kolb favors Common Lisp and the other two favor Scheme, but
the German position allowed for both to be selected and standardized
by ISO.
No other delegation had a written position statement. The Japanese
Delegation consisted of Professor Ito and Mr Kurokawa. Professor Ito
is primarily concerned about CLOS, but after private discussions I
learned that because of lack of study he did not understand it, and
the expert group that advises him consists of object-oriented
programming researchers who press their own ideas on him.
The French Delegation consisted of Jerome Chailloux and Greg Nuyens.
They responded by remarking that the US position represented a
``preposterous'' change in position by the US and directly
contradicted the agreed-upon work item. This work item was the AFNOR
(French) position which was to standardize a Common-Lisp-like dialect
with no packages, simple lambda-lists, simple arrays, generic
functions without classes, a different multiple value system, and a
different syntax for specials. The US argued that this plan was never
voted on because the convener would not allow it: He exaplined that
because it was a technical proposal, it was subject to discussion as
are all other technical points.
The US further remarked that the US position allowed for multiple
standardized dialects, but the convener denied this was possible under
the current work item and suggested we could try introducing a second
work item.
The French delegation contended that the US plan was to block the ISO
process. They were right in the limited sense that I threatened to
block the standardization of any dialect of Common Lisp that was
neither a superset nor a subset of Common Lisp.
I should point out that the French have formally asked SC22 (the
parent group of WG16) whether naming the resulting dialect ``IsLisp''
was allowed because the original work item stated that a standard for
``Lisp'' was being produced. The French commented that the US voted
``yes'' on the work item and that our comment about the name was
irrelevant. Jerome Chailloux's company, ILOG, has a contract from
ESPRIT to produce a draft of ``ISO Lisp.'' In fact, an ESPRIT catalog
we saw stated that the draft had been produced by ILOG in 1987 and was
available on request. However, to our knowledge, there is no ESPRIT
draft document of ``ISO Lisp''. All documents produced by AFNOR and
ILOG refer to ``ISO Lisp.''
As an aside, Chailloux pointed out that he oversees a lot of the
ESPRIT work on AI and that he would not allow any contractor to
use Common Lisp, only ISO Lisp. ILOG advertizes that ISO Lisp will
be available in the first half of 1989 (Beta available in December).
He told Dussud that he would ``have the Germans back in line by
December 15'' (which is the next EuLisp meeting).
The convener declared that discussion on this topic was deadlocked
until AFNOR could meet to decide their response to the US and German
position statements, which would not be until after the Hawaii
meeting. However, the convener told Mathis in private that he did not
want to go to Hawaii and was trying to find a way to cancel the
meeting. The convener also threatened to report failure to SC22 based
on his opinion that a consensus is not possible.
The US delegation agreed to ask X3J13 and the IEEE Scheme groups
whether they were willing to submit drafts under the German proposal.
While so agreeing, we pointed out that the convener was acting as if
the German position would be accepted. I pointed out that the US had
not withdrawn its proposed resolution.
The US delegation repeatedly commented that the US position was
intended to support Common Lisp users and was not intended to prevent
other distinct standards from being established to serve other
communities.
I expect that the word from AFNOR to the European community will be
that the US deliberately tried to block the ISO process, though I'm
not sure what reason he will provide for the US actions.
The second day of the meeting was devoted to three presentations:
Gabriel presented a report on the progress that US Common Lisp vendors
had made in the area of delivery of applications written in Common
Lisp. Mr Kurokawa presented a report on Japanese activity on
provisions within Common Lisp for international character sets. Thom
Linden presented the latest X3J13 work on the same topic. In
addition, the U.S. was asked to present the current WG16 status on
character handling at the next SC22 meeting.
The next ISO meeting is in March in Fairfax, Virginia.
-rpg-
∂29-Nov-88 1546 misha@polya.Stanford.EDU Next aflb
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 15:46:51 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA10159; Tue, 29 Nov 88 15:43:29 PDT
Date: Tue, 29 Nov 88 15:43:29 PDT
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8811292343.AA10159@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: Next aflb
The next AFLB is this Thursday, Dec 1, at 12:30 in room 352 -
the same time and place as usual.
The talk will be:
COMPLEXITY CONSIDERATIONS IN MEMORY HIERARCHIES
ALOK AGGARWAL
IBM Research Division
Yorktown Heights, New York, USA.
In theoretical computer science, algorithms traditionally have
been studied for the random access machine model, in which it is
assumed that memory is unlimited and access to any memory loca-
tion takes unit time. This is not the case in actual computer
systems wherein the time to access a location depends upon its
address. Furthermore, the time to access a block of contiguous
locations is smaller than the total time spent in accessing each
location individually. In this talk, we present and study models
of computation that incorporate the characteristics of such real
machines. Algorithms that take into account nonuniform memory
access cost are developed for well-known problems; most of them
are shown to be optimal by providing matching lower bounds in
these models. Finally, the issue of memory management is studied
-- while on-line memory management is shown to be efficient in
some models, explicit memory management by the user is required
in other models.
-----------------------------------------------------------------
The following AFLB will be a week after that and the speaker will
be Tom Leighton from MIT.
∂29-Nov-88 1716 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Colouring a graph in polynomial time
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 17:16:17 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA13032; Tue, 29 Nov 88 11:38:30 PDT
Message-Id: <8811291938.AA13032@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 29 Nov 88 11:38:22 PST
Received: by BYUADMIN (Mailer R2.01) id 4432; Tue, 29 Nov 88 12:36:29 MST
Date: Tue, 29 Nov 88 13:24:51 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Roger Oscarsson <roger%CS.UMU.SE@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Roger Oscarsson <roger%CS.UMU.SE@Forsythe.Stanford.EDU>
Subject: Colouring a graph in polynomial time
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
I have developed an algorithm which colours an arbitary graph in polynomial
time. As this is a NP-complete problem I have reasons to believe the
algorithm being faulty. I have not proven this algorithm to be correct
(surprise, surprise!), but neither have I proven it to be incorrect. Being
a computer scientist and not a graph theorist I am more into empirical
methods. I have tried it on several graphs and so far it has always managed to
I don't want to publish this algorithm before I can prove it to be correct,
or atleast tried it on numerous cases. I would really appreciate if someone
could send me some nasty graphs to colour, preferably some (all?) of the tests
used in the proof of the four-colouring problem.
AtDhVnAnNkCsE
P.S. I have a friend who is interested in maximal matchings and the vertex-
covering set. Please also send me any information you have on algorithms for
these problems so I can forward it to him.
---
Roger Oscarsson Internet: roger@cs.umu.se
Inst. of Info. Proc Uucp: ...!mcvax!enea!cs.umu.se!roger
Umea University
S-90187 Umea, Sweden
∂29-Nov-88 2046 JONES@Score.Stanford.EDU Do you want TAs for your winter quarter class???
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 20:42:42 PST
Date: Tue 29 Nov 88 20:24:47-PST
From: "H. Roy Jones" <JONES@Score.Stanford.EDU>
Subject: Do you want TAs for your winter quarter class???
To: faculty@Score.Stanford.EDU
cc: stager@Score.Stanford.EDU
Message-ID: <12450577481.11.JONES@Score.Stanford.EDU>
We have a new TA application and appointment process in the works for
Winter Quarter. Applicants are now entering their personal data
and course preferences into a database we've set up on a Mac. We'll be
running lists of applicants for each course , and will send these lists to
course instructors. We would like instructors that are interested in
talking with potential TAs to notify us of hours they will be available
Dead Week, December 5 - 9, to meet with applicants that are interested
enough to stop by. Please inform us by NOON, FRIDAY DECEMBER 2, of
the days, times, office location, and phone number where you will be
available, and we will forward this information to potential TAs. At the
conclusion of your interviews, send your preferences on to Roy Jones
(Jones@Score) and Claire Stager (Stager@Score). Your preferences will be taken
into consideration, as will the preferences of our student applicants, when
TA appointments are being made. If we do not hear from you we will make the
appointments as we have in the past. In any case, we'll make every effort to
inform you of who has been assigned to your course as soon as the appointment
process has been completed.
We hope you'll take advantage of this opportunity to play a larger role in
the TA appointment process. Both you and our students have much to be
gained from ensuring that your classes have the best possible TAs. We
also welcome any suggestions you might have about this process.
In summary, if you'd like to talk to potential TAs for your class next
quarter, please send us the hours you will be available to talk to them next
week by noon this Friday.
Thanks for your help,
Roy
⊗
-------
∂30-Nov-88 1105 barwise@russell.Stanford.EDU statistics
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Nov 88 11:05:40 PST
Received: from localhost by russell.Stanford.EDU (4.0/4.7); Wed, 30 Nov 88 11:06:37 PST
To: ssp-faculty@russell.Stanford.EDU
Subject: statistics
Date: Wed, 30 Nov 88 11:06:36 PST
From: Jon Barwise <barwise@russell.Stanford.EDU>
I thought you might be interested in the following statistics
about the program:
We have 58 majors:
Concentrations:
Artificial Intelligence: 30
Cognition: 9
Philosophical Foundations: 6
Computation: 2
Individually Designed: 3
Language: 0
Applied Logic: 0
Undeclared concentration: 8
∂30-Nov-88 1117 LOGMTC-mailer Seminar in logic and foundations
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Nov 88 11:17:21 PST
Received: by csli.Stanford.EDU (4.0/4.7); Wed, 30 Nov 88 11:16:12 PST
Date: Wed 30 Nov 88 11:16:11-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: Seminar in logic and foundations
To: logic@csli.Stanford.EDU
Message-Id: <596920571.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Seminar in Logic and Foundations of Mathematics
Speaker: Prof. Douglas Bridges, Univ. of Buckingham
Title: "Measurability and nonmeasurability in constructive mathematics"
Time: Monday, Dec.5, 4:15-5:30 PM
Place: Room 381-T, Math Bldg 380, Stanford
There will be a dinner out with the speaker, following the talk.
S. Feferman
-------
∂30-Nov-88 1240 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu theory columnists
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Nov 88 12:40:43 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA18759; Wed, 30 Nov 88 12:40:18 PDT
Message-Id: <8811302040.AA18759@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 30 Nov 88 12:28:52 PST
Received: by BYUADMIN (Mailer R2.01) id 7835; Wed, 30 Nov 88 13:23:02 MST
Date: Wed, 30 Nov 88 13:55:36 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Langston Michael A." <langston%CS2.WSU.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Langston Michael A." <langston%CS2.WSU.EDU@Forsythe.Stanford.EDU>
Subject: theory columnists
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
CALL FOR COLUMNISTS
SIGACT News needs volunteers to write regular technical columns. At present,
only the area of Computational Geometry is covered. Columnists to report on
advances in other areas of theoretical computer science are welcomed.
A column can be published either on a quarterly basis or on a less regular
schedule as the need arises. Become a columnist and help to increase the
visibility of your specific area of research! Volunteers please contact me.
Mike Langston
langston@cs2.wsu.edu
∂30-Nov-88 1558 TAJNAI@Score.Stanford.EDU Extension of deadline for abstracts......
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Nov 88 15:58:23 PST
Date: Wed 30 Nov 88 15:51:34-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Extension of deadline for abstracts......
To: phd@Score.Stanford.EDU, csl-students2@Sierra.Stanford.EDU,
faculty@Score.Stanford.EDU
cc: hiller@Score.Stanford.EDU
Message-ID: <12450789890.51.TAJNAI@Score.Stanford.EDU>
Prof. Feigenbaum, is traveling, and he and I will not be able to work on the
Computer Forum program until next week. Therefore, I'm extending
the deadline until early next week. Monday is preferable, but Tuesday is ok.
I do encourage you to speak to your faculty advisor, and submit an abstract
if you expect to graduate BEFORE February 1990.
Prof. De Micheli is chairing the poster session. If you spoke at last year's
meeting, we suggest you give an update of your work in the poster session.
Also, if you plan to speak at the 22nd Annual Meeting, Feb. 1990, it is highly
recommended that you participate in the Poster Session this year.
Dates: Wednesday/Thursday, February 15/16, 1989 - 21st Annual Meeting
Carolyn Tajnai, Director
Computer Forum
-------
∂30-Nov-88 1611 TAJNAI@Score.Stanford.EDU Magic Pointer for your PHD Oral Examination
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Nov 88 16:11:07 PST
Date: Wed 30 Nov 88 16:00:28-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Magic Pointer for your PHD Oral Examination
To: phd@Score.Stanford.EDU, csl-students@Sierra.Stanford.EDU
cc: hiller@Score.Stanford.EDU, faculty@Score.Stanford.EDU
Message-ID: <12450791509.51.TAJNAI@Score.Stanford.EDU>
It has become a tradition for the Computer Forum to present a magic pointer
to each PHD student to use in her/his oral examination. I try to keep track
of the orals and send messages to the students. Next week 4 are scheduled:
Steve Vavasis, Linda DeMichiel, Xiaolel Qian and Bruce Hitson.
I invite you to stop by the Forum Office, ERL 450, for your Computer Forum
Magic Pointer -- a gift from the Forum.
If someone else is scheduled, or was inadvertently missed, don't hesitate to
come by.
Carolyn Tajnai, Director (and the one who puts the magic on the pointers)
-------
∂30-Nov-88 1632 emma@csli.Stanford.EDU CSLI Calendar, 1 December, 4:10
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Nov 88 16:31:54 PST
Received: by csli.Stanford.EDU (4.0/4.7); Wed, 30 Nov 88 15:59:25 PST
Date: Wed, 30 Nov 88 15:59:25 PST
From: emma@csli.Stanford.EDU (Emma Pease)
To: friends@csli.Stanford.EDU
Subject: CSLI Calendar, 1 December, 4:10
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
1 December 1988 Stanford Vol. 4, No. 10
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 1 December 1988
2:15 p.m. CSLI Seminar
Cordura Hall Week 9: Interpretation as Abduction
Conference Room Jerry Hobbs
(hobbs@ai.sri.com)
Abstract in the last Calendar
3:45 p.m. Tea
Ventura Hall
4:00 p.m. STASS Seminar
Cordura Hall Multimodal, Information-based Inference
Conference Room Jon Barwise, Alan Bush, and John Etchemendy
(barwise@csli.stanford.edu, bush@csli.stanford.edu,
etch@csli.stanford.edu)
Abstract in the last Calendar
____________
ANNOUNCEMENT
Because of final exams and the winter break, there will be no Thursday
events and no Calendar on 8, 15, 22, and 29 December. The next
Calendar will be on 5 January and Thursday events will resume on 12
January.
____________
SYMBOLIC SYSTEMS FORUM
The Languages of Tarski's World
Lauri Karttunen
(karttunen.pa@xerox.com)
Xerox PARC and Dept. of Linguistics, Stanford
Friday, 2 December, 3:15, 60:62N
Tarski's World is the logic teaching Macintosh game designed by
Barwise and Etchemendy. In this world, two languages are spoken:
English and first order logic. One of the objectives of the game is
to teach how these languages are related. The next version of the
program will include a translator that converts English sentences to
logic formulas. My talk will be about the design of the translator,
the grammar of English, and the grammar of logic. How does one get
from
"every cube that is not flanked by a tet is to the left of d"
to
"Ax ((cube(x) & ~Ey(tet(y) & flanks(y,x))) --> left-of(x,d))"?
∂01-Dec-88 1025 hayes.pa@Xerox.COM Re: statistics
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 10:25:11 PST
Received: from Xerox.COM by russell.Stanford.EDU (4.0/4.7); Thu, 1 Dec 88 10:25:08 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 01 DEC 88 10:05:36 PST
Date: 1 Dec 88 10:02 PST
From: hayes.pa@Xerox.COM
Subject: Re: statistics
In-Reply-To: Jon Barwise <barwise@russell.Stanford.EDU>'s message of Wed,
30 Nov 88 11:06:36 PST
To: Jon Barwise <barwise@russell.Stanford.EDU>
Cc: ssp-faculty@russell.Stanford.EDU
Message-Id: <881201-100536-4453@Xerox>
Thanks for the information. Im impressed that there are so many students.
But one worry: any idea why such a high proportion are AI concentrators?
There is just the hint of a danger here, which is that the SSP program is
perhaps being used as a less technical alternative by second-rate computer
science students. Nothing wrong with this in itself, for that matter, but
it is exactly the criticism which some methodologically puritanical CS
faculty have levelled at the program ( indeed at the whole CSLI enterprise
), and so it might be politically astute to be especially sensitive to the
issue, and if it is wrong then having some way to refute it.
Pat
∂01-Dec-88 1117 barwise@russell.Stanford.EDU Re: statistics
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 11:17:34 PST
Received: from localhost by russell.Stanford.EDU (4.0/4.7); Thu, 1 Dec 88 11:18:36 PST
To: hayes.pa@Xerox.COM
Cc: ssp-faculty@russell.Stanford.EDU
Subject: Re: statistics
In-Reply-To: Your message of 01 Dec 88 10:02:00 PST.
<881201-100536-4453@Xerox>
Address: CSLI, Stanford University, Stanford, CA 94305 (415) 723-0110
Date: Thu, 01 Dec 88 11:18:34 PST
From: Jon Barwise <barwise@russell.Stanford.EDU>
Let me say a bit about the numbers. It seems that what attracts
people to the major in the first place is usually an interest in
AI/cog sci sorts of stuff. Some students are disillusioned of their
interest in AI once they learn what it is like. Some of these find
their way to other concentrations, some leave the major.
We have the idea that students will take the core, determine their
interests, and then do a concentration. But in fact, it often seems
to go the other way around. Students put off various core courses,
and only learn about that material at the very end of their studies.
I think this is a contributing factor as to why so few students
concentrate in language or logic. Another problem is that there are
so few undergraduate offerings in some of the concentrations --
especially language and logic.
Pat, I share your concern about looking like a fake cs major. Helen
and I certainly do all we can to persuade the students that SS is not
a substitute for a CS degree. If they want a cs career, then they
should major in CS. I think we all need to reinforce this in our
advising.
Jon
∂01-Dec-88 1312 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu STACS 89
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 13:11:34 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA27193; Thu, 1 Dec 88 13:09:16 PDT
Message-Id: <8812012109.AA27193@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 1 Dec 88 13:09:05 PST
Received: by BYUADMIN (Mailer R2.01) id 7410; Thu, 01 Dec 88 14:04:31 MST
Date: Thu, 1 Dec 88 13:41:53 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Thomas Lengauer <tl%CRATER.UNI-PADERBORN.DE@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Thomas Lengauer <tl%CRATER.UNI-PADERBORN.DE@Forsythe.Stanford.EDU>
Subject: STACS 89
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
6th Annual Symposium on Theoretical Aspects of Computer Science
Universitaet Paderborn, February 16 - 18, 1989
Gesamthochschule
Program
STACS'89
6th Annual Symposium on Theoretical Aspects of Computer Science
organized by Fachausschuss Grundlagen der Informatik der Gesellschaft fuer
Informatik, GI
and College Mathematiques Appliquees, Association Francaise pour
la Cybernetique et Technique, AFCET
sponsored by Deutsche Bank, Paderborn Paderborner Brauerei
Deutsche Forschungsgemeinschaft PESAG, Paderborn
Gundlach KG, Bielefeld Reiche & Co, Lage
Miele & Cie. GmbH & Co., Guetersloh Universitaet-GH
Paderborn
Thursday, February 16, Morning Session
8:50 - 9:00 Opening Address:
Th. Lengauer, L. Priese (Paderborn)
Inivited Speaker:
9:00 - 9:50 Friedhelm Meyer auf der Heide (Dortmund):
On the Complexity of Genuinely Time-Bounded Computations
Session I: Semantics 1
Chairman: R. Cori (Bordeaux)
10:00 - 10:25 Antonio Gavilanes-Franco, Francisca Lucio-Carrasco (Madrid):
A First Order Logic for Partial Functions
10:25 - 10:50 Rolf Hennicker (Passau):
Observational Implementations
BREAK
Session II: Computational Geometry
Chairman: T. Ottmann (Freiburg)
11:15 - 11:40 Panagiotis Alevizos, Jean-Daniel Boissonnat, Franco P.
Preparata (Patras, Valbonne, Urbana):
On the Boundary of a Union of Rays
11:40 - 12:05 Franco P. Preparata, Roberto Tamassia (Urbana):
Dynamic Planar Point Location with Optimal Query Time
12:05 - 12:30 Hristo N. Djidjev, Andrzej Lingas, Joerg-Ruediger Sack
(Sofia, Linkoeping, Ottawa):
An O(n log n) Algorithm for Computing a Link Center in a
Simple Polygon
12:30 - 13:00 Presentation of the Systems Exhibits
LUNCH
Thursday, February 16, Afternoon Session
Parallel Session IIIa: Structures
Chairman: G. Rozenberg (Leiden)
14:00 - 14:25 Wolfgang Gutjahr, Emo Welzl, Gerhart Woeginger (Graz, Berlin):
Polynomial Graph-Colorings
14:25 - 14:50 Friedhelm Meyer auf der Heide, Rolf Wanka (Dortmund):
Time-Optimal Simulations of Networks by Universal Parallel
Computers
14:50 - 15:15 Friedhelm Hinz (Aachen):
Classes of Picture Languages that Cannot Be Distinguished in
the Chain Code Concept and Deletion of Redundant Retreats
Parallel Session IIIb: Automata Theory
Chairman: C. Choffrut (Rouen)
14:00 - 14:25 Christiane Frougny (Paris):
Linear Numeration Systems, Theta - Developments and Finite
Automata
14:25 - 14:50 Jeffrey Shallit (Hannover):
A Generalization of Automatic Sequences
14:50 - 15:15 Volker Diekert (Muenchen):
Word Problems Over Traces Which Are Solvable in Linear Time
BREAK
Parallel Session IVa: Parallel Algorithms
Chairman: F. P. Preparata (Urbana)
15:45 - 16:10 Friedhelm Meyer auf der Heide (Dortmund):
Computing Minimum Spanning Forests on 1- and 2- Dimensional
Processor Arrays
16:10 - 16:35 Otfried Schwarzkopf (Berlin):
Parallel Computation of Discrete Voronoi Diagrams
16:35 - 17:00 Donald Fussell, Ramakrishna Thurimella (Austin):
Successive Approximation in Parallel Graph Algorithms
Parallel Session IVb: Complexity 1
Chairman: U. Schoening (Koblenz)
15:45 - 16:10 Gerhard Buntrock, Albrecht Hoene (Berlin):
Reversals and Alternation
16:10 - 16:35 Jin-yi Cai, Lane A. Hemachandra (New Haven, New York):
On the Power of Parity Polynomial Time
16:35 - 17:00 K. Ganesan, Steven Homer (Boston):
Complete Problems and Strong Polynomial Reducibilities
In the Evening: Reception at the Town Hall, Paderborn
Friday, February 17, Morning Session
Inivited Speaker:
9:00 - 9:50 Peter D. Mosses (Aarhus):
Unified Algebras and Action Semantics
Session V: Complexity 2
Chairman: G. Wechsung (Jena)
10:00 - 10:25 Andrzej Szepietowski (Gdansk):
If Deterministic and Nondeterministic Space Complexities Are
Equal for log log n Then They Are Also Equal for log n
10:25 - 10:50 Piotr Berman, Georg Schnitger (Pennsylvania):
On the Complexity of Approximating the Independent Set Problem
BREAK
Session VI: Distributed Computing
Chairman: J. Berstel (Paris)
11:15 - 11:40 Christian Lavault (Le Chesnay):
Average Number of Messages for Distributed Leader Finding in
Rings of Processors
11:40 - 12:05 Mark Overmars, Nicola Santoro (Utrecht, Bari):
Time vs. Bits
12:05 - 12:30 Paul W. Beame, Hans L. Bodlaender (Seattle, Utrecht):
Distributed Computing on Transitive Networks: The Torus
LUNCH
Friday, February 17, Afternoon Session
Parallel Session VIIa: Fault Tolerance
Chairman: P. Spirakis (Patras, Greece)
14:00 - 14:25 Nicola Santoro, Peter Widmayer (Bari, Karlsruhe):
Time is not a Healer
14:25 - 14:50 Ruediger Reischuk, Bernd Schmeltz (Darmstadt):
Area Efficient Methods to Increase the Reliability of
Combinatorial Circuits
14:50 - 15:15 Juergen Doenhardt (Paderborn):
Fault Masking Probabilities with Single and Multiple Signature
Analysis
Parallel Session VIIb: Semantics 2
Chairman: D. Sannella (Edinburgh)
14:00 - 14:25 Miki Hermann/Paliath Narendran, Jonathan Stillman
(Nancy/Schenectady, Albany):
Chain Properties of Rule Closures/It is Undecidable Whether
the Knuth-Bendix Completion Procedure Generates a Crossed Pair
14:25 - 14:50 Friederike Nickl (Passau):
Algebraic Specifications for Domain Theory
14:50 - 15:15 Aida Batarekh, V.S. Subrahmanian (Syracuse):
The Query Topology in Logic Programming
BREAK
Parallel Session VIIIa: Completeness
Chairman: B. Monien (Paderborn)
15:45 - 16:10 M. Beaudry, P. McKenzie, D. Thaerien (McGill Univ., Montreal):
Testing Membership: Beyond Permutation Groups
16:10 - 16:35 Ernst Mayr (Stanford):
Membership in Polynomial Ideals over Q Is Exponential Space
Complete
16:35 - 17:00 Rakesh M. Verma, I.V. Ramakrishnan (New York):
Tight Complexity Bounds for Some AC Matching Problems
Parallel Session VIIIb: Concurrency
Chairman: M. Wirsing (Passau)
15:45 - 16:10 Bengt Jonsson, Joachim Parrow (Stockholm):
Deciding Bisimulation Equivalences for a Class of
Non-Finite-State Programs
16:10 - 16:35 Bernadette Charron-Bost (Paris):
Measure of Parallelism of Distibuted Computations
16:35 - 17:00 Petr Janvar (Ostrava):
Decidability of Weak Fairness in Petri Nets
19:00 Conference Dinner (at Schalander, Paderborn Brewery)
Saturday, February 18, Morning Session
Inivited Speaker:
9:00 - 9:50 J. Berstel (Paris):
Properties of Infinite Words: Recent Results
Session IX: Formal Languages
Chairman: J. Beauquier (Orsay)
10:00 - 10:25 J.E. Pin, H. Straubing, D. Thaerien (Paris):
New Results on the Generalized Star-Height Problem
10:25 - 10:50 Karel Culik II, Juhani Karhumaeki (Columbia, Turku):
On the Equivalence Problem for Deterministic Multitape
Automata and Transducers
10:50 - 11:15 Helmut Seidl (Saarbruecken):
Deciding Equivalence of Finite Tree Automata
BREAK
Session X: Graph Algorithms
Chairman: K. Mehlhorn (Saarbruecken)
11:40 - 12:05 Marc J. van Kreveld, Mark H. Overmars (Utrecht):
Concatenable Segment Trees
12:05 - 12:30 Andreas Schwill (Oldenburg):
Shortest Edge-Disjoint Paths in Graphs
12:30 - 12:55 Bala Kalyanasundaram, Georg Schnitger (Pennsylvania):
Rounds versus Time for the Two Person Pebble Game
SYSTEMS
M. Morandi Cecchi, F. Nachira, O. Viele (Padova):
AXE: The Syntax Driven Diagram Editor for Visual Languages used in the Software
Engineering Environments AxIS
Michael Himsolt (Passau):
GraphEd: An Interactive Editor for Graphs
M. Jaeger (Darmstadt):
SAMPLE: A Language Dependent Prototyping Environment
Tomasz Janowski (Gdansk):
Examining the Satisfiability of the Formulas of Propositional Dynamic Logic
A. Maier, A. Potthoff, W. Thomas, U. Wermuth (Aachen):
AMORE - A System for Computing Automata, Monoids, and Regular Expressions
Olov Schelaen (Lulea):
A Proof System for Type Theory and CCS
Thomas Wolff (Berlin):
A Semantics Oriented Interpreter for a Language for Concepts of Concurrency
Program Committee Organizing Committee
J. Beauquier (Orsay) T. Lengauer (Paderborn)
E. Boerger (Pisa) L. Priese (Paderborn)
C. Choffrut (Rouen)
R. Cori (Bordeaux), Co-Chairman
B. Monien (Paderborn), Co-Chairman
T. Ottmann (Freiburg)
G. Rozenberg (Leiden) Symposium Address:
D. Sanella (Edinburgh)
U. Schoening (Koblenz) Frau Petra Scheike
P. Spirakis (Patras) Universitaet-GH Paderborn
J.M. Steyaert (Paloiseau) Warburger Str. 100
G. Wechsung (Jena) 4790 Paderborn
M. Wirsing (Passau) West Germany
Telefon: +495251/602654
e-mail: scheike@pbinfo.uucp or
...!unido!pbinfo!scheike
Location Conference Fees
The sessions will be held at The fee includes admission to all
technical sessions, a copy of the
Universitaet-GH Paderborn conference proceedings, refreshments, and
Hoersaal D1, D2. the conference dinner.
Follow STACS-signs! before Jan. 10, 1989 after Jan. 10, 1989
member
Registration office: of GI, afcet DM 150 DM 180
The registration office is at non-member DM 190 DM 220
Hoersaal D1/D2 and is open: students DM 25 DM 40
(without proceedings)
Wednesday 15.00 - 19.00
Thursday 8.00 - 17.00 Make check (in DM) payable to "STACS'89" or
Friday 8.00 - 17.00 transfer the amount to:
Saturday 9.00 - 12.00 Lutz Priese, Sonderkonto GI
Deutsche Bank Paderborn (BLZ 472 700 29)
Account Number: 5231253
and send completed form together with check or
copy of deposit slip to the symposium address.
Please use the Registration Form.
Registration Form Return to:
STACS'89 P. Scheike
Universitaet-GH Paderborn
Fachbereich 17
Warburger Str. 100
4790 Paderborn
Name: ___________________________________
Address: ________________________________
________________________________
________________________________
________________________________
Tel.: ________________________________
Payment ___ cheque enclosed
___ by money order
Signature: ______________________________
Room Reservation Return to:
STACS'89 Verkehrsverein Paderborn
Marienplatz 2a
______ Single 4790 Paderborn
______ Double
___ A DM 99,-- and higher
___ B DM 45,-- - DM 85,--
___ C DM 25,-- - DM 40,--
___ Second choice: ___ A, ___ B, ___ C
Arrival: Date: _________ Time: _________
Departure: Date: _________ Time: _________
Arrival: ___ by Car ___ by Train, Plane
Name: _____________________________________
Address: __________________________________
__________________________________
__________________________________
__________________________________
__________________________________
Tel.: __________________________________
Transportation:
Paderborn can be reached by train either via Dortmund or Hamm (from the West)
or via Kassel (from the South and North). There are good night train
connections (Paris - Warsaw). Paderborn has an airport (Paderborn/Lippstadt)
with regular service to Berlin, Frankfurt, Munich, and Stuttgart. However, the
airport may be closed for short periods because of seasonal weather
(fog, snow).
Weather:
May be above or below freezing. In fact, weather is quite unpredictable, either
being a strong winter or spring-like warmth. Hope for the best!
∂01-Dec-88 1347 hayes.pa@Xerox.COM Re: statistics
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 13:46:35 PST
Received: from Xerox.COM by russell.Stanford.EDU (4.0/4.7); Thu, 1 Dec 88 13:47:41 PST
Received: from Semillon.ms by ArpaGateway.ms ; 01 DEC 88 13:28:17 PST
Date: 1 Dec 88 13:27 PST
From: hayes.pa@Xerox.COM
Subject: Re: statistics
In-Reply-To: Jon Barwise <barwise@russell.Stanford.EDU>'s message of Thu,
01 Dec 88 11:18:34 PST
To: Jon Barwise <barwise@russell.Stanford.EDU>
Cc: ssp-faculty@russell.Stanford.EDU
Message-Id: <881201-132817-4977@Xerox>
Thanks. I dont mean to harp on this fake-CS point: I am probably
ultrasensitive to it because it hurt us in Rochester. I am sure that you
and Helen work hard to give students an honest and sensible appraisal of
what SS is and isnt.
Your point about students simply not seeing any linguistics or logic
because of delay in their core-course attendance had not occurred to me.
Maybe this is one way the the considerable energies of our SSP Forum
organiser could be utilised: how about a series of informal Friday talks by
faculty on the excitement of their discipline and why it is of crucial
importance to SS and why any SS student with a spark of imagination would
want to concentrate in it, etc.. These might be deliberately controversial
in a goodnatured way, which might draw audiences ( I imagine word going
around that Prof. X is going to say why his area is much better than Prof
Ys area is.. )
Has this been tried already?
Pat
∂01-Dec-88 1404 SHOHAM@Score.Stanford.EDU numbers
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 14:04:28 PST
Received: from Score.Stanford.EDU by csli.Stanford.EDU (4.0/4.7); Thu, 1 Dec 88 14:02:16 PST
Date: Thu 1 Dec 88 14:02:13-PST
From: Yoav Shoham <SHOHAM@Score.Stanford.EDU>
Subject: numbers
To: ssp-faculty@CSLI.Stanford.EDU
Message-Id: <12451032127.37.SHOHAM@Score.Stanford.EDU>
I too was struck by the proportions. I think increasing the awareness of
students of the intellectual challenges is a good idea. I'm not sure
a competitive theme, even a mock one, will be a constructive thing to
introduce. I've tried the opposite - express admiration for the other
disciplines, pointing out the intellectual limits of doing CS, and
the practical disadvantages of practicing it outside a CS department.
Hasn't worked so far though has it.
Yoav
-------
∂01-Dec-88 1432 littell@polya.Stanford.EDU Winter quarter RA appointments
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 14:32:42 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA19215; Thu, 1 Dec 88 11:35:01 PDT
Date: Thu, 1 Dec 88 11:35:01 PDT
From: Angelina M. Littell <littell@polya.Stanford.EDU>
Message-Id: <8812011935.AA19215@polya.Stanford.EDU>
To: faclist@polya.Stanford.EDU
Cc: littell@polya.Stanford.EDU, bergman@score
Subject: Winter quarter RA appointments
Please send me a list of students you plan on supporting during the
winter quarter, along with their source of support and percentage of
time. I need this information as soon as possible. The RA appointment
forms need to be processed soon to insure the student receives a bill
with the correct tuition applied. The appointments should reach the
Graduate Awards Office before Dec. 14th.
Thank you.
--Angie
∂01-Dec-88 1455 devlin@csli.Stanford.EDU SS numbers
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 14:55:44 PST
Received: by csli.Stanford.EDU (4.0/4.7); Thu, 1 Dec 88 14:53:59 PST
Date: Thu 1 Dec 88 14:53:58-PST
From: Keith Devlin <DEVLIN@CSLI.Stanford.EDU>
Subject: SS numbers
To: ssp-faculty@csli.Stanford.EDU
Message-Id: <597020038.0.DEVLIN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Re: Concentrations in SSP.
Seems to me that any interdisiplinary program will run the risk of
being thought of as a "soft option" by each of the contributory
disiplines. To think of SSP as "weak CS" sounds very much like the
view that was common amongst mathematicians until fairly recently
(maybe now they just keep quiet) that CS was a soft option for weak
mathematicians. The aims and issues are different. (Of course, this
is not to say that a lot of "failed" mathematicians did not end up
doing computer science, possibly even very good computer science.
But so what?)
Personally, I have found working on SSP type research far "harder"
than my previous work in the "hard" subject of mathematics, since
it requires trying to get at the same problems from quite different
perspectives, using methodologies one is not familiar with, all the
while looking for bridges to link the various approaches. I cannot
imagine it is so different for a student.
Maybe the real reason for the AI concentration is not so much that SSP
attracts a lot of CS people who want a relief from mathematically based
stuff, but that it puts off a lot of people from other disciplines who
do not have the requisite mathematical background.
Keith
-------
∂01-Dec-88 1505 der@elrond.Stanford.EDU Re: numbers
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 15:02:41 PST
Received: from elrond.Stanford.EDU by csli.Stanford.EDU (4.0/4.7); Thu, 1 Dec 88 15:01:01 PST
Received: by elrond.Stanford.EDU (3.2/4.7); Thu, 1 Dec 88 15:01:14 PST
Date: Thu, 1 Dec 88 15:01:14 PST
From: der@elrond.Stanford.EDU (Dave Rumelhart)
To: ssp-faculty@CSLI.Stanford.EDU
Subject: Re: numbers
As dull as it may be, I suspect that there is a rather simple explanation
fop the distribution of numbers. Although we all are primarily interested
in the ideas (we already have jobs) the students -- even the best of them --
wonder about what they are going to do when they leave here and how --
eventually -- they are going to make a living. I suspect that, rightly or
wrongly, many of them believe that if all else fails (i.e. they don't
get into a graduate school of their choice or they can't get an academic
job of their choice) that they may have to make a living from computers.
So, they want to make sure they have enough recorded knowledge (i.e. courses
on their transscript etc.) that they can get a job using computers. I
suspect that rather than a weaker version of CS, we actually have a stronger
version -- we have the students who are willing to take more of a chance and
spend their time studying more of the stuff they are really interested in
(i.e. the nature of mind) and less of their time making sure they
have a job in the future. I suspect they just don't know what kind of job
they might have if they did a concentration in logic or in linguistics. This
is not to say that they are right their judgements of future employment options,
it is just that I'll bet it is a real concern for some of the students. If I
am right we should either (1) tell them that there a plenty of opportunities
out there for SSP majors with a concentration in logic or linguistics or (2)
(If their judgements have any truth in them.) not begrudge them the right to
hedge their bets a bit.
der
∂01-Dec-88 1523 helen@russell.Stanford.EDU numbers
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 15:23:22 PST
Received: by russell.Stanford.EDU (4.0/4.7); Thu, 1 Dec 88 15:24:23 PST
Date: Thu 1 Dec 88 15:24:22-PST
From: Helen Nissenbaum <HELEN@CSLI.Stanford.EDU>
Subject: numbers
To: ssp-faculty@russell.Stanford.EDU
Message-Id: <597021862.0.HELEN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Let me add my observations abou numbers in the AI track:
I think it is -- or at least appears to students to be -- a fairly
diverse concentration. So within it, students focus on different things
for example: computational linguistics, cognition and AI, AI programming,
knowledge representation, etc. Students are fairly evenly spread across
these areas.
The uneven distribution of SSP majors across concentrations, from my
perspective, presents a practical problem. That is, how on earth to find
advisors for everyone while at the same time sticking to our initial goal
of matching student and advisor interest.
We're exploring various alternatives, that dont involve further swamping
those of you who already have too many advisees, but would welcome
suggestions, ideas to follow up, etc.
--Helen
-------
∂01-Dec-88 1701 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu STACS 89
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 17:00:48 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA27193; Thu, 1 Dec 88 13:09:16 PDT
Message-Id: <8812012109.AA27193@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 1 Dec 88 13:09:05 PST
Received: by BYUADMIN (Mailer R2.01) id 7410; Thu, 01 Dec 88 14:04:31 MST
Date: Thu, 1 Dec 88 13:41:53 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Thomas Lengauer <tl%CRATER.UNI-PADERBORN.DE@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Thomas Lengauer <tl%CRATER.UNI-PADERBORN.DE@Forsythe.Stanford.EDU>
Subject: STACS 89
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
6th Annual Symposium on Theoretical Aspects of Computer Science
Universitaet Paderborn, February 16 - 18, 1989
Gesamthochschule
Program
STACS'89
6th Annual Symposium on Theoretical Aspects of Computer Science
organized by Fachausschuss Grundlagen der Informatik der Gesellschaft fuer
Informatik, GI
and College Mathematiques Appliquees, Association Francaise pour
la Cybernetique et Technique, AFCET
sponsored by Deutsche Bank, Paderborn Paderborner Brauerei
Deutsche Forschungsgemeinschaft PESAG, Paderborn
Gundlach KG, Bielefeld Reiche & Co, Lage
Miele & Cie. GmbH & Co., Guetersloh Universitaet-GH
Paderborn
Thursday, February 16, Morning Session
8:50 - 9:00 Opening Address:
Th. Lengauer, L. Priese (Paderborn)
Inivited Speaker:
9:00 - 9:50 Friedhelm Meyer auf der Heide (Dortmund):
On the Complexity of Genuinely Time-Bounded Computations
Session I: Semantics 1
Chairman: R. Cori (Bordeaux)
10:00 - 10:25 Antonio Gavilanes-Franco, Francisca Lucio-Carrasco (Madrid):
A First Order Logic for Partial Functions
10:25 - 10:50 Rolf Hennicker (Passau):
Observational Implementations
BREAK
Session II: Computational Geometry
Chairman: T. Ottmann (Freiburg)
11:15 - 11:40 Panagiotis Alevizos, Jean-Daniel Boissonnat, Franco P.
Preparata (Patras, Valbonne, Urbana):
On the Boundary of a Union of Rays
11:40 - 12:05 Franco P. Preparata, Roberto Tamassia (Urbana):
Dynamic Planar Point Location with Optimal Query Time
12:05 - 12:30 Hristo N. Djidjev, Andrzej Lingas, Joerg-Ruediger Sack
(Sofia, Linkoeping, Ottawa):
An O(n log n) Algorithm for Computing a Link Center in a
Simple Polygon
12:30 - 13:00 Presentation of the Systems Exhibits
LUNCH
Thursday, February 16, Afternoon Session
Parallel Session IIIa: Structures
Chairman: G. Rozenberg (Leiden)
14:00 - 14:25 Wolfgang Gutjahr, Emo Welzl, Gerhart Woeginger (Graz, Berlin):
Polynomial Graph-Colorings
14:25 - 14:50 Friedhelm Meyer auf der Heide, Rolf Wanka (Dortmund):
Time-Optimal Simulations of Networks by Universal Parallel
Computers
14:50 - 15:15 Friedhelm Hinz (Aachen):
Classes of Picture Languages that Cannot Be Distinguished in
the Chain Code Concept and Deletion of Redundant Retreats
Parallel Session IIIb: Automata Theory
Chairman: C. Choffrut (Rouen)
14:00 - 14:25 Christiane Frougny (Paris):
Linear Numeration Systems, Theta - Developments and Finite
Automata
14:25 - 14:50 Jeffrey Shallit (Hannover):
A Generalization of Automatic Sequences
14:50 - 15:15 Volker Diekert (Muenchen):
Word Problems Over Traces Which Are Solvable in Linear Time
BREAK
Parallel Session IVa: Parallel Algorithms
Chairman: F. P. Preparata (Urbana)
15:45 - 16:10 Friedhelm Meyer auf der Heide (Dortmund):
Computing Minimum Spanning Forests on 1- and 2- Dimensional
Processor Arrays
16:10 - 16:35 Otfried Schwarzkopf (Berlin):
Parallel Computation of Discrete Voronoi Diagrams
16:35 - 17:00 Donald Fussell, Ramakrishna Thurimella (Austin):
Successive Approximation in Parallel Graph Algorithms
Parallel Session IVb: Complexity 1
Chairman: U. Schoening (Koblenz)
15:45 - 16:10 Gerhard Buntrock, Albrecht Hoene (Berlin):
Reversals and Alternation
16:10 - 16:35 Jin-yi Cai, Lane A. Hemachandra (New Haven, New York):
On the Power of Parity Polynomial Time
16:35 - 17:00 K. Ganesan, Steven Homer (Boston):
Complete Problems and Strong Polynomial Reducibilities
In the Evening: Reception at the Town Hall, Paderborn
Friday, February 17, Morning Session
Inivited Speaker:
9:00 - 9:50 Peter D. Mosses (Aarhus):
Unified Algebras and Action Semantics
Session V: Complexity 2
Chairman: G. Wechsung (Jena)
10:00 - 10:25 Andrzej Szepietowski (Gdansk):
If Deterministic and Nondeterministic Space Complexities Are
Equal for log log n Then They Are Also Equal for log n
10:25 - 10:50 Piotr Berman, Georg Schnitger (Pennsylvania):
On the Complexity of Approximating the Independent Set Problem
BREAK
Session VI: Distributed Computing
Chairman: J. Berstel (Paris)
11:15 - 11:40 Christian Lavault (Le Chesnay):
Average Number of Messages for Distributed Leader Finding in
Rings of Processors
11:40 - 12:05 Mark Overmars, Nicola Santoro (Utrecht, Bari):
Time vs. Bits
12:05 - 12:30 Paul W. Beame, Hans L. Bodlaender (Seattle, Utrecht):
Distributed Computing on Transitive Networks: The Torus
LUNCH
Friday, February 17, Afternoon Session
Parallel Session VIIa: Fault Tolerance
Chairman: P. Spirakis (Patras, Greece)
14:00 - 14:25 Nicola Santoro, Peter Widmayer (Bari, Karlsruhe):
Time is not a Healer
14:25 - 14:50 Ruediger Reischuk, Bernd Schmeltz (Darmstadt):
Area Efficient Methods to Increase the Reliability of
Combinatorial Circuits
14:50 - 15:15 Juergen Doenhardt (Paderborn):
Fault Masking Probabilities with Single and Multiple Signature
Analysis
Parallel Session VIIb: Semantics 2
Chairman: D. Sannella (Edinburgh)
14:00 - 14:25 Miki Hermann/Paliath Narendran, Jonathan Stillman
(Nancy/Schenectady, Albany):
Chain Properties of Rule Closures/It is Undecidable Whether
the Knuth-Bendix Completion Procedure Generates a Crossed Pair
14:25 - 14:50 Friederike Nickl (Passau):
Algebraic Specifications for Domain Theory
14:50 - 15:15 Aida Batarekh, V.S. Subrahmanian (Syracuse):
The Query Topology in Logic Programming
BREAK
Parallel Session VIIIa: Completeness
Chairman: B. Monien (Paderborn)
15:45 - 16:10 M. Beaudry, P. McKenzie, D. Thaerien (McGill Univ., Montreal):
Testing Membership: Beyond Permutation Groups
16:10 - 16:35 Ernst Mayr (Stanford):
Membership in Polynomial Ideals over Q Is Exponential Space
Complete
16:35 - 17:00 Rakesh M. Verma, I.V. Ramakrishnan (New York):
Tight Complexity Bounds for Some AC Matching Problems
Parallel Session VIIIb: Concurrency
Chairman: M. Wirsing (Passau)
15:45 - 16:10 Bengt Jonsson, Joachim Parrow (Stockholm):
Deciding Bisimulation Equivalences for a Class of
Non-Finite-State Programs
16:10 - 16:35 Bernadette Charron-Bost (Paris):
Measure of Parallelism of Distibuted Computations
16:35 - 17:00 Petr Janvar (Ostrava):
Decidability of Weak Fairness in Petri Nets
19:00 Conference Dinner (at Schalander, Paderborn Brewery)
Saturday, February 18, Morning Session
Inivited Speaker:
9:00 - 9:50 J. Berstel (Paris):
Properties of Infinite Words: Recent Results
Session IX: Formal Languages
Chairman: J. Beauquier (Orsay)
10:00 - 10:25 J.E. Pin, H. Straubing, D. Thaerien (Paris):
New Results on the Generalized Star-Height Problem
10:25 - 10:50 Karel Culik II, Juhani Karhumaeki (Columbia, Turku):
On the Equivalence Problem for Deterministic Multitape
Automata and Transducers
10:50 - 11:15 Helmut Seidl (Saarbruecken):
Deciding Equivalence of Finite Tree Automata
BREAK
Session X: Graph Algorithms
Chairman: K. Mehlhorn (Saarbruecken)
11:40 - 12:05 Marc J. van Kreveld, Mark H. Overmars (Utrecht):
Concatenable Segment Trees
12:05 - 12:30 Andreas Schwill (Oldenburg):
Shortest Edge-Disjoint Paths in Graphs
12:30 - 12:55 Bala Kalyanasundaram, Georg Schnitger (Pennsylvania):
Rounds versus Time for the Two Person Pebble Game
SYSTEMS
M. Morandi Cecchi, F. Nachira, O. Viele (Padova):
AXE: The Syntax Driven Diagram Editor for Visual Languages used in the Software
Engineering Environments AxIS
Michael Himsolt (Passau):
GraphEd: An Interactive Editor for Graphs
M. Jaeger (Darmstadt):
SAMPLE: A Language Dependent Prototyping Environment
Tomasz Janowski (Gdansk):
Examining the Satisfiability of the Formulas of Propositional Dynamic Logic
A. Maier, A. Potthoff, W. Thomas, U. Wermuth (Aachen):
AMORE - A System for Computing Automata, Monoids, and Regular Expressions
Olov Schelaen (Lulea):
A Proof System for Type Theory and CCS
Thomas Wolff (Berlin):
A Semantics Oriented Interpreter for a Language for Concepts of Concurrency
Program Committee Organizing Committee
J. Beauquier (Orsay) T. Lengauer (Paderborn)
E. Boerger (Pisa) L. Priese (Paderborn)
C. Choffrut (Rouen)
R. Cori (Bordeaux), Co-Chairman
B. Monien (Paderborn), Co-Chairman
T. Ottmann (Freiburg)
G. Rozenberg (Leiden) Symposium Address:
D. Sanella (Edinburgh)
U. Schoening (Koblenz) Frau Petra Scheike
P. Spirakis (Patras) Universitaet-GH Paderborn
J.M. Steyaert (Paloiseau) Warburger Str. 100
G. Wechsung (Jena) 4790 Paderborn
M. Wirsing (Passau) West Germany
Telefon: +495251/602654
e-mail: scheike@pbinfo.uucp or
...!unido!pbinfo!scheike
Location Conference Fees
The sessions will be held at The fee includes admission to all
technical sessions, a copy of the
Universitaet-GH Paderborn conference proceedings, refreshments, and
Hoersaal D1, D2. the conference dinner.
Follow STACS-signs! before Jan. 10, 1989 after Jan. 10, 1989
member
Registration office: of GI, afcet DM 150 DM 180
The registration office is at non-member DM 190 DM 220
Hoersaal D1/D2 and is open: students DM 25 DM 40
(without proceedings)
Wednesday 15.00 - 19.00
Thursday 8.00 - 17.00 Make check (in DM) payable to "STACS'89" or
Friday 8.00 - 17.00 transfer the amount to:
Saturday 9.00 - 12.00 Lutz Priese, Sonderkonto GI
Deutsche Bank Paderborn (BLZ 472 700 29)
Account Number: 5231253
and send completed form together with check or
copy of deposit slip to the symposium address.
Please use the Registration Form.
Registration Form Return to:
STACS'89 P. Scheike
Universitaet-GH Paderborn
Fachbereich 17
Warburger Str. 100
4790 Paderborn
Name: ___________________________________
Address: ________________________________
________________________________
________________________________
________________________________
Tel.: ________________________________
Payment ___ cheque enclosed
___ by money order
Signature: ______________________________
Room Reservation Return to:
STACS'89 Verkehrsverein Paderborn
Marienplatz 2a
______ Single 4790 Paderborn
______ Double
___ A DM 99,-- and higher
___ B DM 45,-- - DM 85,--
___ C DM 25,-- - DM 40,--
___ Second choice: ___ A, ___ B, ___ C
Arrival: Date: _________ Time: _________
Departure: Date: _________ Time: _________
Arrival: ___ by Car ___ by Train, Plane
Name: _____________________________________
Address: __________________________________
__________________________________
__________________________________
__________________________________
__________________________________
Tel.: __________________________________
Transportation:
Paderborn can be reached by train either via Dortmund or Hamm (from the West)
or via Kassel (from the South and North). There are good night train
connections (Paris - Warsaw). Paderborn has an airport (Paderborn/Lippstadt)
with regular service to Berlin, Frankfurt, Munich, and Stuttgart. However, the
airport may be closed for short periods because of seasonal weather
(fog, snow).
Weather:
May be above or below freezing. In fact, weather is quite unpredictable, either
being a strong winter or spring-like warmth. Hope for the best!
∂01-Dec-88 1754 @polya.Stanford.EDU:tah@linz MTC Seminar
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 17:52:44 PST
Received: from linz.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA18995; Thu, 1 Dec 88 17:50:18 PDT
Received: by linz.stanford.edu (5.59/25-eef) id AA19038; Thu, 1 Dec 88 17:47:57 PDT
Message-Id: <8812020147.AA19038@linz.stanford.edu>
To: lop@polya
Subject: MTC Seminar
Date: 01 Dec 88 17:47:54 PST (Thu)
From: Tom Henzinger <tah@linz>
Liz is going to continue to lead the discussion about initiality and
finality and all that tomorrow (Dec. 2).
Next week (Dec. 9) John Williams from IBM Almaden will give a talk on
FL (the successor of FP).
-- Tom.
∂01-Dec-88 1913 hayes.pa@Xerox.COM Re: SS numbers
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 19:12:58 PST
Received: from Xerox.COM by csli.Stanford.EDU (4.0/4.7); Thu, 1 Dec 88 19:10:56 PST
Received: from Semillon.ms by ArpaGateway.ms ; 01 DEC 88 18:15:02 PST
Date: 1 Dec 88 18:14 PST
From: hayes.pa@Xerox.COM
Subject: Re: SS numbers
In-Reply-To: Keith Devlin <DEVLIN@CSLI.Stanford.EDU>'s message of Thu, 1
Dec 88 14:53:58 PST
To: Keith Devlin <DEVLIN@CSLI.Stanford.EDU>
Cc: ssp-faculty@csli.Stanford.EDU
Message-Id: <881201-181502-5588@Xerox>
I completely agree with you about interdisciplinary rigors: please dont
misunderstand me, I was only anxious about the impression that our
statistics might make, and the ammunition they might provide for the
enemies of interdisiplinary initiatives. It is exactly the need to be able
to look at the subject from many perspectives, without being already
committed to one disciplines professional criteria of correctness, which
makes an undergraduate course of this kind so valuable, in my view: we can
give the students a many-sided perspective which they could not get from
any one discipline, and which they will carry with them even when they go
on to graduate work in one of the component areas and, by necessity, come
to use and support that areas particular methods and criteria of
professionalism.
Who knows what the real reason for the imbalance is. It may be temporary,
caused in part by the undoubted high visibility of AI in the culture at
present. I recall when I used to be embarrased to tell people that my
field was AI, because they thought I was joking and would laugh: I used to
apologise in advance for the silly name. Nowadays people are impressed, and
ask me about smart robots in orbit.
Pat
∂01-Dec-88 1922 hayes.pa@Xerox.COM second-rate
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 19:22:11 PST
Received: from Xerox.COM by russell.Stanford.EDU (4.0/4.7); Thu, 1 Dec 88 19:23:30 PST
Received: from Semillon.ms by ArpaGateway.ms ; 01 DEC 88 18:45:16 PST
Date: 1 Dec 88 18:44 PST
From: hayes.pa@Xerox.COM
Subject: second-rate
To: ssp-faculty@russell.stanford.edu
Message-Id: <881201-184516-5642@Xerox>
Let me apologise to everyone for using the term "second-rate computer
science students". I meant to convey a certain attitude towards this ( or
indeed, any other interdisciplinary ) degree, but my phrasing has clearly
offended many. I certainly did not mean to imply that any of the SS
students ARE second-rate, or that such cross-disciplinary work is somehow
easier than mainstream work, or somehow a dilution of it. ( I used to be a
Luce professor: all Luce professors hold multidisciplinary positions,
usually crossing department boundaries, and we know how hard it is. )
There is a perspective on this which regards CS as a something like a
medieval guild, and a degree in it to be a sort of licence to practice, and
which has some contempt for students who want to do the gilding but are
unable or unwilling to learn the basic stonecraft; and is irritated by
guild members who allow such lazy folk the wherewithal to get a
qualification and pretend to be real craftsmen: this is, from their point
of view, almost the ultimate unprofessional conduct for a teacher, and they
see it as something close to a moral duty to stamp it out. I have heard
deep suspicion voiced about the SS degree, and the danger that was
perceived was precisely this: that it would enable students who werent
properly qualified as CSists to somehow pretend that they were semi-CSists
because they had done the glamorous courses, when in fact they didnt really
know a byte from a pixel: and, worse, they perhaps ( or even probably )
were incapable of doing the really tough stuff. I would guess that there
may be some psychologists who have analogous concerns - do these graduates
really know how to design an experiment? This is the attitude and
perspective which I meant to convey: not because it is right, but because
the figures might fit it so neatly.
Pat
∂01-Dec-88 2105 devlin@csli.Stanford.EDU Re: SS numbers
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 21:05:25 PST
Received: by csli.Stanford.EDU (4.0/4.7); Thu, 1 Dec 88 21:03:51 PST
Date: Thu 1 Dec 88 21:03:50-PST
From: Keith Devlin <DEVLIN@CSLI.Stanford.EDU>
Subject: Re: SS numbers
To: hayes.pa@XEROX.COM
Cc: ssp-faculty@CSLI.Stanford.EDU
Message-Id: <597042230.0.DEVLIN@CSLI.Stanford.EDU>
In-Reply-To: <881201-181502-5588@Xerox>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Pat,
That was how I took your message, as I am sure everyone else
did. The "judgement" issue strikes me as a real danger when
it comes to university politics and research funding. (My two
attempts to fund my work in the UK before I came here - I was
just beginning on this stuff then - both fell through when the
SERC math committee declared it to be CS and the CS committee
declared it to be math.)
Keith
-------
∂02-Dec-88 1059 @Score.Stanford.EDU:goldberg@Jinn.stanford.edu Visiting Profs meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Dec 88 10:56:41 PST
Received: from Jinn.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 2 Dec 88 10:53:47-PST
Received: by Jinn.stanford.edu (4.0/25-eef) id AA09201; Fri, 2 Dec 88 10:55:06 PST
Date: Fri, 2 Dec 88 10:55:06 PST
From: Andrew Goldberg <goldberg@Jinn.stanford.edu>
Message-Id: <8812021855.AA09201@Jinn.stanford.edu>
To: faculty@score
Subject: Visiting Profs meeting
The visiting professors committee will meet on December 12 in MJH 301.
We will look at candidates for Visiting Professor and Industrial Lecturer
positions.
--Andy
∂02-Dec-88 1315 hoffman@csli.Stanford.EDU Philosophy Colloquium Dec. 9
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Dec 88 13:15:28 PST
Received: by csli.Stanford.EDU (4.0/4.7); Fri, 2 Dec 88 12:51:27 PST
Date: Fri 2 Dec 88 12:51:25-PST
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: Philosophy Colloquium Dec. 9
To: hoffman@csli.Stanford.EDU
Cc: forum-faculty@csli.Stanford.EDU, ssp-forum@csli.Stanford.EDU
Message-Id: <597099085.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
I did not schedule any Symbolic Systems Forum for the 9th because it is
dead week and everyone will probably be scribbling away in the library
on their finals. There is, however, a philosophy colloquium in the
philosopy building (#90 in the quad) which I am informing you about.
Daniel Isaacson of Oxford U. (now visiting UCB) will speak on
"Quine and Logical Truth"
Merry Christmas all!
-------
∂02-Dec-88 1355 @Score.Stanford.EDU:wheaton@athena.stanford.edu Exedra model
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Dec 88 13:54:54 PST
Received: from athena.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 2 Dec 88 13:51:03-PST
Received: by athena.stanford.edu (5.59/25-eef) id AA18061; Fri, 2 Dec 88 13:51:46 PDT
Date: Fri, 2 Dec 88 13:51:46 PDT
From: George Wheaton <wheaton@athena.stanford.edu>
Message-Id: <8812022151.AA18061@athena.stanford.edu>
To: faculty@score, bureaucrats@polya
Subject: Exedra model
I have a small model of the new building in my office. This one is in
living color (red roof, sandstone walls) and gives a good perspective
of the overall building appearance. I have to leave early this
afternoon, but I'll put the model in Joyce's office when I go. Anyone
who wants to see it, come on by.
gw
∂02-Dec-88 1406 @Score.Stanford.EDU:wheaton@athena.stanford.edu Nox/Sox Communications
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Dec 88 14:06:09 PST
Received: from athena.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 2 Dec 88 14:03:24-PST
Received: by athena.stanford.edu (5.59/25-eef) id AA18074; Fri, 2 Dec 88 14:04:12 PDT
Date: Fri, 2 Dec 88 14:04:12 PDT
From: George Wheaton <wheaton@athena.stanford.edu>
Message-Id: <8812022204.AA18074@athena.stanford.edu>
To: faculty@score
Subject: Nox/Sox Communications
Wayne Paulson of Project Management has prepared a draft document
describing plans for communications/faceplate services in the Exedra
buildings. Now is the time to comment or suggest changes as DEC has
been selected as the communications consultant on the job, and they
are preparing their final proposal.
We will put copies in faculty mailboxes (probably early next week);
anyone else who would like a copy should see Joyce.
gw
∂02-Dec-88 1429 alur@polya.Stanford.EDU Vaughan's example
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Dec 88 14:29:24 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA00911; Fri, 2 Dec 88 14:27:05 PDT
Date: Fri, 2 Dec 88 14:27:05 PDT
From: Rajeev Alur <alur@polya.Stanford.EDU>
Message-Id: <8812022227.AA00911@polya.Stanford.EDU>
To: lop@polya.Stanford.EDU
Subject: Vaughan's example
Today in MTC seminar Vaughan gave the example of points in plane.
T1 had axioms : Up(point(x,y) = point(x,y+1)
across(point(x,y)) = point(x+1,y)
then he said across(up(p))=up(across(p)) is not provable, but could be
added in T2. But this axiom is already true in the initial semantics of T1.
(in initial model all elements of plane are of the form 'point(m,n)')
I would like to know if I am missing something and if not why consider
T2 rejecting the initial semantics of T1.
thanks
rajeev
∂02-Dec-88 1500 @polya.Stanford.EDU:jcm@ra.stanford.edu Re: Vaughan's example
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Dec 88 14:59:57 PST
Received: from ra.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA03267; Fri, 2 Dec 88 14:58:35 PDT
Received: by ra.stanford.edu (5.59/25-eef) id AA06569; Fri, 2 Dec 88 14:58:05 PDT
Date: Fri, 2 Dec 88 14:58:05 PDT
From: John Mitchell <jcm@ra.stanford.edu>
Message-Id: <8812022258.AA06569@ra.stanford.edu>
To: lop@polya.Stanford.EDU
Subject: Re: Vaughan's example
Sounds like Vaughan was missing something (as was I
in accepting his example). I think that his axioms
included
up(point(x,y)) = point(x,y+1)
across(point(x,y)) = point(x+1,y)
which seem to me now (unless I am missing something)
to make across(up(p))=up(across(p)) true in the initial
algebra of T1, for the reason you pointed out.
However, the point he was trying to illustrate seems
reasonable to me. Let me try another example.
Suppose T0 has sorts nat, bool and functions
0:nat; S:nat->nat; EQ?:nat,nat -> bool,
true, false:bool and
conditionals over nat and bool. (you add the
obvious axioms). The initial algebra for T0
should be natural numbers and booleans.
Let T1 be T0 + sort set and functions
empty: set
insert: nat, set -> set
ismem?: nat,set -> bool
with equational axioms
ismem?(x,empty) = false
ismem?(x,insert(x,s)) = if eq?(x,y) then true
else ismem?(x,s)
Since there are no equations beteen set expressions,
the initial algebra for T1 has elements that "remember"
which order elements were added to the set.
However, the final algebra satisfies equations
like insert(x,insert(y,empty)) = insert(y,insert(x,empty)),
since this does not collapse integers or booleans.
John
∂02-Dec-88 1738 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Hard graphs to color
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Dec 88 17:37:52 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA27451; Fri, 2 Dec 88 17:36:57 PDT
Message-Id: <8812030136.AA27451@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 2 Dec 88 17:36:47 PST
Received: by BYUADMIN (Mailer R2.01) id 4403; Fri, 02 Dec 88 17:31:17 MST
Date: Fri, 2 Dec 88 15:08:13 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
dsj@RESEARCH.ATT.COM
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: dsj@RESEARCH.ATT.COM
Subject: Hard graphs to color
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Roger Oscarsson recently requested some hard graphs to color, so as to
test a proposed algorithm. Fortunately, coloring is one problem for which
random graphs are difficult, so he can generate his own.
One would expect any two large random graphs to have the same chromatic
number, and so one can rely on earlier results to establish minimal
standards which any optimization algorithm must meet.
For instance, it seems, based on experiments with heuristics that run
for 100+ hours on a VAX-750, that the chromatic number of the 1000 vertex
random graph (edge probability = 0.5) is 85 or less, so any
proposed optimization algorithm should do at least this well.
(As to lower bounds, all we know is that such graphs almost surely require
at least 80 colors.)
(If your "polynomial time" algorithm is too slow to handle graphs of this
size, n = 500 still offers a challenge. Here you'll know that your algorithm
has failed if it uses more than 49 colors, the current heuristic best;
the lower bound is 46. For n = 250, the figures are 29 and 27.)
David S. Johnson, AT&T Bell Laboratories (dsj@research.att.com)
∂02-Dec-88 2351 X3J13-mailer re: ISO meeting report
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 2 Dec 88 23:50:31 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA29272; Sat, 3 Dec 88 01:32:29 EST
Received: by mcvax.cwi.nl via EUnet; Sat, 3 Dec 88 07:05:56 +0100 (MET)
Received: by inria.inria.fr via Fnet-EUnet; Sat, 3 Dec 88 00:19:19 +0100 (MET)
Date: Sat, 3 Dec 88 00:19:19 +0100
From: mcvax!inria.inria.fr!chaillou@uunet.UU.NET (Jerome Chailloux)
Message-Id: <8812022319.AA10635@inria.inria.fr>
To: x3j13@sail.stanford.edu
Subject: re: ISO meeting report
Dear X3J13 members,
as an X3J13 Observer, I have several remarks on the Richard Gabriel's report
on the last WG16 meeting, held in Brussels the 21st and 22nd of November 88.
This report contains mistakes and doesn't reflect the many discussions
actually held during the meeting following the new ANSI position and the
DIN proposal. Please ask ANSI to distribute the official report of the
third meeting of WG16 to the members of X3J13.
But in addition of the incompleteness, there are some large mistakes in the
Mr Gabriel's report that I have to correct immediately:
1) the name of the standard
"I should point out that the French have formally asked SC22 (the
parent group of WG16) whether naming the resulting dialect ``IsLisp''
was allowed because the original work item stated that a standard for
``Lisp'' was being produced. The French commented that the US voted
``yes'' on the work item and that our comment about the name was
irrelevant."
False! This issue has been discussed at the first meeting at Paris. One
can read in the "Draft report of the 1st meeting of ISO/IEC JTC1/SC22/WG16
LISP," page 7 which is the official document WG16 Lisp N 12, which has been
approved at the second meeting at Snowbird:
"...
After several rounds of straw votes ISLISP was accepted.
The Secretariat was asked to let ISO Central Secretariat
in Geneva know such a change compared to the initial title
of the New Work Item.
..."
The AFNOR delegation has only asked if ISO in Geneva had given an answer.
2) ESPRIT
"Jerome Chailloux's company, ILOG, has a contract from
ESPRIT to produce a draft of ``ISO Lisp.'' In fact, an ESPRIT catalog
we saw stated that the draft had been produced by ILOG in 1987 and was
available on request. However, to our knowledge, there is no ESPRIT
draft document of ``ISO Lisp''. All documents produced by AFNOR and
ILOG refer to ``ISO Lisp.''"
Wrong! and not discussed at all at the Brussels meeting which was obviously
not the right place to discuss that! ILOG has no Esprit contract to
produce a draft of ISO Lisp! If Mr Gabriel refers to the "Technical
Interest Group: Lisp" funded by the Esprit Program, please let him quote
the exact and complete description of this TIG (from the 1987 annual report
ISBN 92-825-8999-4). If you want to hear a fair explanation I would say:
Since 1986 the Esprit Program has funded a TIG, called "EuLisp", to
prepare the standardization of Lisp and to produce a draft to be proposed at
what is called now WG16. This TIG is funded on a per-person basis and has
nothing to do with companies (the majority of the participants are in fact
academic).
3) ESPRIT (again)
"As an aside, Chailloux pointed out that he oversees a lot of the
ESPRIT work on AI and that he would not allow any contractor to
use Common Lisp, only ISO Lisp."
Ridiculous! I am not in position to decide such policy. Please Mr Gabriel,
give the exact wording of the introductory speech of Mr Omnes (from the
EEC). He said that 30% of the Esprit II Program will use Lisp and that a
standard (preferably an ISO Standard) is warmly desired and that the
promotion of standards is in the charter of the Esprit Program.
4) ILOG Advertising
"ILOG advertizes that ISO Lisp will be available in the first
half of 1989 (Beta available in December)."
Can Mr Gabriel, give us the reference of the ILOG advertisement that he
refers to?
5) Next EuLisp Meeting
"He told Dussud that he would ``have the Germans back in line by
December 15'' (which is the next EuLisp meeting)."
Again, this is wrong! At the next EuLisp meeting in December, the different
representatives of the european national organisation of standardisation
will try to have a common position in regard with the work done at WG16
because, despite the fact than some members of ANSI claim the contrary, it
seems to many that the new ANSI position will give a significant change of
direction of the work of WG16. This "radical" change has to be
discussed at different member bodies and then at the EuLisp meeting,
which seems reasonable at an International Working Group.
Jerome Chailloux
AFNOR representative at ISO WG16.
∂03-Dec-88 1635 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu retreat?
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Dec 88 16:35:53 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sat 3 Dec 88 16:33:19-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA21517; Sat, 3 Dec 88 16:33:49 PDT
Date: Sat, 3 Dec 88 16:33:49 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8812040033.AA21517@Tenaya.stanford.edu>
To: faculty@score
Subject: retreat?
Several people have asked me if we are going to have another
faculty retreat this year. I think all who attended the one
this past May at Chaminade thought it was valuable. Should
we try another? If so, when? And should it have the same
format?
Please help us decide by e-mailing back the following form to
Joyce:
1. On a scale of 0 to 100, I think the importance of
having a CSD/CSL retreat this academic year is:
(0 => shouldn't have a retreat; 100 => should have a retreat)
(No response to this message interpreted as a "0".)
2. It should be at Chaminade again ( yes); ( no).
If no, this time let's try another place, namely:
3. Technical subjects only ( yes); ( no).
If no, let's also talk about:
4. Good times to have the retreat:
(please name some favorite weekends, maybe augmented by a Friday
or Monday)
5. Terrible times to have the retreat:
(please list definite times to avoid)
Thanks, -Nils
∂04-Dec-88 1821 @polya.Stanford.EDU:coraki!pratt@Sun.COM Points example
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Dec 88 18:21:31 PST
Received: from SUN.COM by polya.Stanford.EDU (5.59/25-eef) id AA01328; Sun, 4 Dec 88 18:20:20 PDT
Received: from sun.Sun.COM (sun-bb.sun.com) by Sun.COM (4.1/SMI-4.0)
id AA11388; Sun, 4 Dec 88 18:22:55 PST
Received: from coraki.UUCP by sun.Sun.COM (4.0/SMI-4.0)
id AA05592; Sun, 4 Dec 88 18:19:49 PST
Received: by (4.0/SMI-4.0Beta)
id AA20968; Sun, 4 Dec 88 18:18:44 PST
Date: Sun, 4 Dec 88 18:18:44 PST
From: Vaughan Pratt <coraki!pratt@Sun.COM>
Message-Id: <8812050218.AA20968@>
To: lop@polya.stanford.edu
Subject: Points example
Cc: coraki!pratt@Sun.COM
Oops, Rajeev is right, T1 is "categorical" in the sense that is already
strong enough to squeeze together its initial and Wand-final algebras,
making my example technically correct but trivial. What I was trying
for was something where Across and Up did not commute in the initial
algebra of T1 but did in the Wand-final algebra of T0->T1.
A small change to T1 ought to get this effect while preserving the
simplicity I was striving for. Just replace the Point function by a
constant point Org and redefine Across and Up accordingly. (In
retrospect PLANE is a bad name for that sort, POINT would be better and
is now available so I'll use it.) So my example becomes
T0:
0 : NAT
+1 : NAT -> NAT
T1:
Org : POINT
X,Y : POINT -> NAT
Across,Up : POINT -> POINT
X(Org) = Y(Org) = 0
X(Across(p)) = X(p)+1
Y(Across(p)) = Y(p)
X(Up(p)) = X(p)
Y(Up(p)) = Y(p)+1
The new ground terms of the old sort (NAT) are all terms of the form
{X,Y}{Across,Up}*Org, e.g. X(Across(Up(Up(Org)))), and can be seen by
induction to be equivalent to old ground terms.
In the initial algebra of T1, NAT has its standard interpretation as a
chain starting at 0, while POINT forms a binary tree rooted at Org and
with every node p having two descendants Across(p) and Up(p), i.e. we
remember how we got to the point from the origin. Indeed every "point"
is really a path from the origin to a point.
The Wand-final algebra of T0->T1 is then this initial algebra of T1
collapsed to a dag, namely the standard plane (or rather upper right
quadrant thereof). That is, we divide the initial algebra of T1 by the
congruence "p leads to the same point as q".
This example is meant to illustrate only the principle behind
Wand-finality, not its utility. After all we can obtain T2 from T1
merely by adding
Up(Across(p)) = Across(Up(p))
What utility there may be in Wand's method of augmenting T1 to T2 must
reside in his remark about failure of Church-Rosser, I'd appreciate it
if someone would explain what Mitch has in mind here.
Incidentally, from an algebraic perspective what we have described are
three free monoids. The initial algebra of T0 is the free monoid on
one generator, that of T1 the free monoid on two generators, and that
of T2 the free commutative monoid on two generators. I don't have any
general conclusion to draw from this. However it is noteworthy that
all the examples we've seen so far, namely Mitch's, John's, and mine,
seem to have commutativity of certain compositions (Up;Across =
Across;Up) as the basic contribution of Wand augmentation.
This naturally raises the question of what other kinds of contributions
can Wand augmentation make? Here's one, a variant of John's example,
where it contributes both commutativity and associativity (of an
explicit binary operation, namely multiset union, rather than of
composition which is implicit for us). The important variant is to use
Union instead of Insert, in order to have a binary operation that can
be associative. Mem(x, s) yields the number of occurrences of natural
number x in multiset s. To make Mem easy to define I've defined NAT
not as the initial algebra with signature 0,SUC but (in essence) as the
free monoid on one generator. (Commutativity of + follows from
initiality.) Not having BOOL around complicates equality testing, but
it is good to practice with examples of observability with and without
BOOL. In general however it is probably simplest to rely on BOOL and
Eq? as John did.
T0:
0,1 : NAT
+ : NAT x NAT -> NAT
0+x = x = x+0
(x+y)+z = x+(y+z)
T1:
Empty : MULTISET
Union : MULTISET x MULTISET -> MULTISET
Singleton: NAT -> MULTISET
Mem : NAT x MULTISET -> NAT
Mem(x, Empty) = 0
Mem(x, Union(s, t)) = Mem(x,s)+Mem(x,t)
Mem(x, Singleton(x)) = 1
Mem(x, Singleton(x+y+1)) = 0 = Mem(x+y+1, Singleton(x))
Had we defined another operation | : NAT x NAT -> NAT to be logical or
(as in C's operation ||, which returns 1 except for 0||0 == 1) and
axiomatized Mem as
Mem(x, Union(s, t)) = Mem(x,s)|Mem(x,t)
then the Wand-final algebra would be SET rather than MULTISET, and T2
would then automatically pick up an identity saying that Union was
idempotent. (This of course is better done with the help of BOOL and
its operations.)
-v
∂05-Dec-88 0335 @polya.Stanford.EDU:tah@linz Re: points example
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Dec 88 03:35:18 PST
Received: from linz.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA17910; Mon, 5 Dec 88 03:34:23 PDT
Received: by linz.stanford.edu (5.59/25-eef) id AA26263; Mon, 5 Dec 88 03:30:42 PDT
Message-Id: <8812051130.AA26263@linz.stanford.edu>
To: lop@polya
Subject: Re: points example
Date: 05 Dec 88 03:30:34 PST (Mon)
From: Tom Henzinger <tah@linz>
One interesting property of the final algebra is that every true equation
can be proved by "consistency" (or "inductionless induction," as this seems
to be called in the ADT community); that is, every equation that
can be added without destroying the consistency of the theory holds in the
final model. Therefore, we can prove that an equation E is true in the final
model by applying the Knuth-Bendix algorithm to the axioms augmented by E
and showing that the resulting complete rewrite system does not identify
TRUE with FALSE.
The Knuth-Bendix approach to prove consistency works of course only for
theories that can be characterized by a complete (i.e., Church-Rosser and
terminating) rewrite system. T1 in both John's and Mitch Wand's examples
lose this desirable property if the "commutative" axiom (say,
insert(x,insert(y,s))=insert(y,insert(x,s))) were required. So there's
some "utility" to being able to do without those axioms.
Vaughan's points example, on the other hand, has a complete rewrite system
even with the equation
(E) Across(Up(p)) = Up(Across(p)),
which can be oriented either way. (The normal forms of Across-Up paths will
either have all Across's followed by all Up's or vice versa.) Therefore,
this example can be used to demonstrate a "proof by consistency," that E
holds in the final model of T1, which has the following complete rewrite
system:
X(Org) -> 0
Y(Org) -> 0
X(Across(p)) -> S(X(p))
Y(Across(p)) -> Y(p)
X(Up(p)) -> X(p)
Y(Up(p)) -> S(Y(p))
To show E, we add the rewrite rule
Across(Up(p)) -> Up(Across(p)),
which gives rise to the critical pairs <X(Up(Across(p))),S(X(Up(p)))> and
<Y(Up(Across(p))),Y(Up(p))>, both of which are already confluent, so
the augmented rewrite system is complete. S(0)=0 is still unprovable by
rewriting, thus E is true in the final model of the points theory.
-tom
∂05-Dec-88 0836 TAJNAI@Score.Stanford.EDU AT&T Bell Fellowship
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Dec 88 08:36:31 PST
Date: Mon 5 Dec 88 08:34:10-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: AT&T Bell Fellowship
To: Katz@Polya.Stanford.EDU, lincoln@Polya.Stanford.EDU,
scales@Polya.Stanford.EDU
cc: faculty@Score.Stanford.EDU
Message-ID: <12452020984.20.TAJNAI@Score.Stanford.EDU>
TO: Morris Katz, Patrick Lincoln, Daniel Scales:
The faculty has nominated you to submit an application for the AT&T
Bell Fellowship. We are asked to submit 3 nominations and one of you will
be selected. It is a 4 year fellowship.
I need the following from each of you by Monday, 9 January.
1. completed application form: a form will be sent to your student mailbox.
2. transcripts of grades from all undergraduate and graduate schools attended.
You can get an unofficial transcript from the Stanford registrar,
and I'll authenticate it.
3. statement of your research interests.
4. Letters of recommendation from professors with whom you may pursue the
thesis research and who can evaluate your ability and potential. Additional
letters of recommendation are welcome. Note: I realize you may not have
selected your faculty advisor since this is your first year. However, ask the
faculty members (I suggest 3) with whom you are best acquainted. If you have
questions, feel free to ask me.
Congratulations on being selected by the faculty. I wish all 3 of you could
win!
Carolyn Tajnai, Chairman
CSD Fellowship Committee
-------
∂05-Dec-88 0957 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu analysis of parallel algorithms ( machine indepedent)
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Dec 88 09:57:28 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA24811; Mon, 5 Dec 88 09:57:08 PDT
Message-Id: <8812051757.AA24811@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 5 Dec 88 09:57:46 PST
Received: by BYUADMIN (Mailer R2.01) id 6483; Mon, 05 Dec 88 10:55:50 MST
Date: Mon, 5 Dec 88 11:42:39 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Hai-Ning Liu <liu%BEOWULF.UCSD.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Hai-Ning Liu <liu%BEOWULF.UCSD.EDU@Forsythe.Stanford.EDU>
Subject: analysis of parallel algorithms ( machine indepedent)
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
I am interested in results about communication delay between any two
processors. Note this is different from PRAM model. Right now I am
looking for theoretical papers. e.g. "Towards an
Architecture-Independent Analysis of Parallel Algorithms" by
Papadimitriou and Yannakakis.
My email address is liu@cs.ucsd.edu.
Thank you.
--liu
From: liu@beowulf.ucsd.edu (Hai-Ning Liu)
Path: beowulf!liu
CSE dept H.N. Liu
C-014
UCSD
∂05-Dec-88 1031 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Tomorrow's Faculty Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Dec 88 10:31:09 PST
Received: from polya.Stanford.EDU by Score.Stanford.EDU with TCP; Mon 5 Dec 88 10:19:43-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA25881; Mon, 5 Dec 88 10:20:15 PDT
Date: Mon, 5 Dec 1988 10:20:06 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score
Subject: Tomorrow's Faculty Lunch
Message-Id: <CMM.0.87.597349206.chandler@polya.stanford.edu>
Don't forget tomorrow's faculty lunch. Jim Gibbons will our guest. Same
time 12:15, same place - MJH146. See you there!
∂05-Dec-88 1141 rajeev@polya.Stanford.EDU CS304 vs. CS366 next quarter
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Dec 88 11:41:00 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA01295; Mon, 5 Dec 88 11:40:13 PDT
Date: Mon, 5 Dec 88 11:40:13 PDT
From: Rajeev Motwani <rajeev@polya.Stanford.EDU>
Message-Id: <8812051940.AA01295@polya.Stanford.EDU>
To: aflb-su@polya.Stanford.EDU, new-phd@polya.Stanford.EDU
Subject: CS304 vs. CS366 next quarter
Cc: dek@sail, rajeev@polya.Stanford.EDU
I am trying to find out how many people would like to
attend both CS304 (Knuth) and CS 366 next quarter. I
will schedule CS 366 in the same time slot as CS304
unless someone objects to it.
An alternative time slot is MW 2:15-3:30, this might
cause problems for those who intend to attend CS309 (Diffie).
Let me know if you will face this conflict.
I am including a course description of CS366 for your
information.
Rajeev Motwani
CS366 - LOWER BOUNDS
--------------------
INSTRUCTOR: Rajeev Motwani
PREREQUISITES: CS264 or equivalent background.
COURSE DESCRIPTION: This course will be concerned with techniques for
establishing limits on the possible efficiency of algorithms. Various
models of computation will be defined with the aim of capturing some
aspects of the performance of an algorithm including: running time,
space requirement and communication costs. For each model of
computation lower bounds and, if possible, tight upper bounds on some
measure of an algorithms performance will be presented. The models
of computation to be considered will be drawn from the following list.
(a) Comparison Tree Model & Information Theory Bounds
(b) Algebraic Computation Trees
(c) Evasiveness of Graph Properties
(d) Communication Complexity
(e) Pebbling Games: Straight Line Programs and Space-Time Trade-offs
(f) Branching Programs and Space-Time Trade-offs
(g) The PRAM Model: Lower Bounds for Parallel Computation
(h) Circuit Complexity
∂05-Dec-88 1209 X3J13-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Dec 88 12:06:03 PST
Received: from Semillon.ms by ArpaGateway.ms ; 05 DEC 88 11:45:41 PST
Date: 5 Dec 88 11:45 PST
Sender: masinter.pa@Xerox.COM
to: X3J13@Sail.stanford.edu
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
from: CL-Cleanup@Sail.Stanford.edu
REPLY-TO: cl-cleanup@Sail.Stanford.Edu
cc: Masinter.pa@Xerox.COM
Line-fold: NO
Message-ID: <881205-114541-3846@Xerox>
This is the first of a number of issues for which we have prepared
new versions since the October meeting. There will be a hardcopy
mailing of issues and a ballot; details in a separate message later.
Ballot issues will also be available for anonymous FTP from host
arisia.xerox.com in the directory clcleanup/pending.
As usual, if you have any comments, questions, please respond
to CL-CLEANUP@Sail.stanford.edu rather than to the entire
X3J13 list.
!
Forum: Cleanup
Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
References: Data types and Type specifiers: CLtL p. 11; Sect. 4.5, p.45
Functions: TYPEP and SUBTYPEP; CLtL Sect. 6.2.1, p.72
ARRAY-ELEMENT-TYPE, CLtL p. 291
The type-specifiers:
ARRAY, SIMPLE-ARRAY, VECTOR, SIMPLE-VECTOR
COMPLEX
Related Issues: SUBTYPEP-TOO-VAGUE, LIST-TYPE-SPECIFIER
Category: CHANGE
Edit history: Version 1, 13-May-88, JonL
Version 2, 23-May-88, JonL
(typo fixes, comments from moon, rearrange some discussion)
Version 3, 02-Jun-88, JonL
(flush alternate proposal ["flush-upgrading"]; consequently,
move more of discussion back to discussion section.
Version 4, 01-Oct-88, Jan Pedersen & JonL
(reduce discussion, and "cleanup" wordings)
(Version 5 edit history missing)
Version 6, 6-Oct-88, Moon
(fix typos, cover subtypep explicitly, add complex,
change name of UPGRADE-ARRAY-ELEMENT-TYPE)
Version 7, 7-Oct-88, JonL (more name and wording changes)
Version 8, 8-Oct-88, Masinter (wording, discussion)
Version 9, 31-Oct-88, JonL (major re-wording to accommodate
recent discussion; esp. re-introduce and clarify "upgrading")
Problem description:
CLtL occasionally draws a distinction between type-specifiers "for
declaration" and "for discrimination"; see CLtL, section 4.5 "Type
Specifiers That Specialize" (p.45 and following) The phrase
"for declaration" encompasses type-specifiers passed in as the
:element-type argument to MAKE-ARRAY, passed in as the <result-type>
argument to COERCE, and used in THE and DECLARE type declarations. The
phrase "for discrimination" refers to the type-specifiers passed in as
the <type> argument(s) to TYPEP and SUBTYPEP.
One consequence of this distinction is that a variable declared to be of
type <certain-type>, and all of whose assigned objects are created in
accordance with that type, may still have none of its values ever satisfy
the TYPEP predicate with that type-specifier. One type-specifier with
this property is
(ARRAY <element-type>)
for various implementation dependent values of <element-type>. For
example, in most implementations of CL, an array X created with an
element-type of (SIGNED-BYTE 5) will, depending on the vendor, either
satisfy
(TYPEP X '(ARRAY (SIGNED-BYTE 8))), or
(TYPEP X '(ARRAY T))
but (almost) never will it satisfy
(TYPEP X '(ARRAY (SIGNED-BYTE 5))).
This is entirely permissible within the scope of standardization on
MAKE-ARRAY, where an implementation is required only to construct up the
result out of "the most specialized [element] type that can nevertheless
accommodate elements of the given type [the :element-type argument]"
(see CLtL, p287). That is, an implementation may in fact only provide a
very small number of equivalence classes of element-types for storing
arrays, corresponding to its repertoire of specialized storage techniques;
and it is explicitly permitted to "upgrade" any element-type request into
one of its built-in repertoire (see also CLtL, p45, second and third
paragraphs under Section 4.5.)
As a practical matter, almost every existing implementation does some
serious upgrading of the :element-type argument given to MAKE-ARRAY.
Yet the difference between "for declaration" and "for discrimination"
has been very confusing to many people. Similarly, portability is
hindered when users do not know just how a given implementation does
upgrading.
The type specifier (COMPLEX <part-type>) also falls in the domain of CLtL
Section 4.5. Currently, only one implementation actually provides any kind
of specialized storage for complex parts; and in this case, the practical
matter is less urgent, since the kind of upgrading happening is so obvious
as to cause little or no confusion.
Proposal: (ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING)
Short Summary:
** Eliminate the distinction between type-specifiers "for declaration" and
"for discrimination". In short, change the meaning of array and
complex type specifiers in favor of the "for declaration" meaning.
** Change the meaning of TYPEP to be in accord with "for declaration"
meaning of type-specifiers.
** Add an implementation-dependent function that reveals how a given
type-specifier for array element-types is upgraded. Add another such
function that reveals how a given type-specifier for complex parts is
upgraded.
** Clarify that "upgrading" implies a movement upwards in the type-
hierarchy lattice; i.e., if <type> upgrades to <Type>, then
<Type> must be a super-type of <type>.
** Clarify that upgrading an array element-type is independent of any
other property of arrays, such as rank, adjustability, fill-pointers,
etc.
** Clarify how SUBTYPEP thus behaves on array type-specifiers.
** Define how SUBTYPEP behaves on complex type-specifiers.
Note that despite this issue's name, the detailed specifications herein
apply to the type system -- not to the behavior of MAKE-ARRAY, nor to how
arrays are actually implemented.
Details:
First, some definitions: Two type-specifiers <type1> and <type2> are said
to be "type-equivalent" if and only if each one specifies a subtype of the
other one. For example, (UNSIGNED-BYTE 5) and (MOD 32) are two different
type- specifiers that always refer to the same sets of things; hence they
are type-equivalent. But (UNSIGNED-BYTE 5) and (SIGNED-BYTE 8) are not
type- equivalent since the former refers to a proper subset of the latter.
Two type-specifiers <type1> and <type2> are said to be "type-disjoint"
if their specified intersection is null. For example, INTEGER and FLOAT
are type disjoint by definition (see CLtL p.33), and (INTEGER 3 5) and
(INTEGER 7 10) are type-disjoint because the specified ranges have no
elements in common.
*. Eliminate the distinction between types "for declaration" and "for
discrimination". In particular, elminate any such reference in the
discussion of array and complex type-specifiers; this would include
documentation patterned after the discussion in section 4.5, pp. 45-7,
especially the example on p.46 that says "See ARRAY-ELEMENT-TYPE".
Change the meaning of (ARRAY <element-type>), as well as any of the
subtypes of ARRAY (such as SIMPLE-ARRAY, VECTOR, etc.) in favor of the
"for declaration" meaning. Make the similar simplification for the
<part-type> specifiers in the COMPLEX type-specifier.
*. Change the meaning of (TYPEP <x> '(ARRAY <type>)), where <type> is not
*, to be true if and only if <x> is an array that could be the result
of giving <type> as the :element-type argument to MAKE-ARRAY. While
(ARRAY *) refers to all arrays regardless of element type, (ARRAY <type>)
refers only to those arrays that can result from giving <type> as the
:element-type argument to the function MAKE-ARRAY. Change the meanings
for (SIMPLE-ARRAY <type>) and (VECTOR <type>) in the same way.
Change the meaning of (TYPEP <x> '(COMPLEX <type>)) similarly. Thus,
(COMPLEX <type>) refers to all complex numbers that can result from
giving numbers of type <type> to the function COMPLEX, plus all other
complex numbers of the same specialized representation. Remember that
both the real and the imaginary parts of any such complex number must
satisfy:
(TYPEP <real-or-imag-part> '<type>).
*. Add the function UPGRADED-ARRAY-ELEMENT-TYPE of one argument, which
returns the element type of the most specialized array representation
capable of holding items of the given argument type. Note that except
for storage allocation consequences, it could be defined as:
(DEFUN UPGRADED-ARRAY-ELEMENT-TYPE (TYPE)
(ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE TYPE)))
Since element-type upgrading is a fundamental operation implicit in
almost every existing implementation of MAKE-ARRAY, the purpose of this
added function is primarily to reveal how an implementation does its
upgrading.
Add the function UPGRADED-COMPLEX-PART-TYPE of one argument that
returns the part type of the most specialized complex number
representation that can hold parts of the given argument type.
*. Clarify that "upgrading" implies a movement upwards in the type-
hierarchy lattice. Specifically, the type-specifier <type> must be
a subtype of (UPGRADED-ARRAY-ELEMENT-TYPE '<type>). Furthermore, if
<type1> is a subtype of <type2>, then:
(UPGRADED-ARRAY-ELEMENT-TYPE '<type1>)
must also be a subtype of:
(UPGRADED-ARRAY-ELEMENT-TYPE '<type2>).
Note however, that two type-disjoint types can in fact be upgraded into
the same thing.
Clarify that ARRAY-ELEMENT-TYPE returns the upgraded element type
for the array; in particular, any documentation patterned after
the sentence on p. 291 begining "This set may be larger than the
set requested when the array was created; for example . . ." should
be embellished with this clarification.
Similarly, the type-specifier <type> must be a subtype of
(UPGRADED-COMPLEX-PART-TYPE <type>).
*. Clarify that upgrading an array element-type is independent of any
other property of arrays, such as rank, adjustability, fill-pointers,
displacement etc. For all such properties other than rank this should
be obvious (since they are not expressible in the language of
type-specifiers); but note that unless it is also independent of rank,
it would not be consistently possible to displace arrays to those of
differing rank.
*. Clarify that SUBTYPEP on ARRAY type-specifiers is as follows:
For all type-specifiers <type1> and <type2> other than *, require
(ARRAY <type1>) and (ARRAY <type2>) to be type-equivalent if and only
if they refer to arrays of exactly the same specialized representation;
and require them to be type-disjoint if and only if they refer to arrays
of different, distinct specialized representations. This definition
follows that implicitly prescribed in CLtL.
As a consequence of the preceding change to TYPEP and of the definition
of UPGRADED-ARRAY-ELEMENT-TYPE, the two type specifiers
(ARRAY <type1>) and
(ARRAY <type2>)
are type-equivalent if and only if
(UPGRADED-ARRAY-ELEMENT-TYPE '<type1>) and
(UPGRADED-ARRAY-ELEMENT-TYPE '<type2>)
are type-equivalent. This is another way of saying that `(ARRAY <type>)
and `(ARRAY ,(UPGRADED-ARRAY-ELEMENT-TYPE '<type>)) refer to the same
set of specialized array representations.
This defines the behavior of SUBTYPEP on array type-specifiers; namely:
(SUBTYPEP '(ARRAY <type1>) '(ARRAY <type2>))
is true if and only if
(UPGRADED-ARRAY-ELEMENT-TYPE '<type1>) and
(UPGRADED-ARRAY-ELEMENT-TYPE '<type2>)
are type-equivalent.
*. Define SUBTYPEP on COMPLEX type-specifiers as follows:
For all type-specifiers <type1> and <type2> other than *,
(SUBTYPEP '(COMPLEX <type1>) '(COMPLEX <type2>))
is T T if:
1. <type1> is a subtype of <type2>, or
2. (UPGRADED-COMPLEX-PART-TYPE '<type1>) is type-equivalent
to (UPGRADED-COMPLEX-PART-TYPE '<type2>); in this case,
(COMPLEX <type1>) and (COMPLEX <type2>) both refer to the
same specialized representation.
The result is NIL T otherwise.
The small differences between the SUBTYPEP specification for ARRAY and
for COMPLEX are necessary because there is no creation function for
complexes which allows one to specify the resultant part type independently
of the actual types of the parts. Thus in the case of COMPLEX, we must
refer to the actual type of the parts, although a number can be a member
of more than one type; e.g., 17 is of type (MOD 18) as well as of type
(MOD 256); and 2.3f5 is of type SINGLE-FLOAT was well as FLOAT.
The form:
(SUBTYPEP '(COMPLEX SINGLE-FLOAT) '(COMPLEX FLOAT))
must be true in all implementations; but:
(SUBTYPEP '(ARRAY SINGLE-FLOAT) '(ARRAY FLOAT))
is true only in implementations that do not have a specialized array
representation for single-floats distinct from that for other floats.
Examples:
Let <aet-x> and <aet-y> be two distinct type specifiers that are
definitely not type-equivalent in a given implementation, but for which
make-array will return an object of the same array type. This will be
an implementation dependent search, but in every implementation that
the proposer has tested, there will be some such types; often,
(SIGNED-BYTE 5) and (SIGNED-BYTE 8) will work.
Thus, in each case, both of the following forms return T T:
(subtypep (array-element-type (make-array 0 :element-type '<aet-x>))
(array-element-type (make-array 0 :element-type '<aet-y>)))
(subtypep (array-element-type (make-array 0 :element-type '<aet-y>))
(array-element-type (make-array 0 :element-type '<aet-x>)))
To eliminate the distinction between "for declaration" and "for
discrimination" both of the following should be true:
[A]
(typep (make-array 0 :element-type '<aet-x>)
'(array <aet-x>))
(typep (make-array 0 :element-type '<aet-y>)
'(array <aet-y>))
Since (array <aet-x>) and (array <aet-y>) are different names for
exactly the same set of objects, these names should be type-equivalent.
That implies that the following set of tests should also be true:
[B]
(subtypep '(array <aet-x>) '(array <aet-y>))
(subtypep '(array <aet-y>) '(array <aet-x>))
Additionally, to show that un-equivalent type-specifiers that use the
same specialized array type should be equivalent as element-type
specifiers, the following type tests should be true:
[C]
(typep (make-array 0 :element-type '<aet-y>)
'(array <aet-x>))
(typep (make-array 0 :element-type '<aet-x>)
'(array <aet-y>))
Rationale:
This proposal legitimizes current practice, and removes the obscure and
un-useful distinction between type-specifiers "for declaration" and
"for discrimination". The suggested changes to the interpretation of
array and complex type-specifiers follow from defining type-specifiers
as names for collections of objects, on TYPEP being a set membership
test, and SUBTYPEP a subset test on collections of objects.
Current Practice:
Every vendor's implementation that the proposer has queried has a finite
set of specialized array representations, such that two non-equivalent
element types can be found that use the same specialized array
representation; this includes Lucid, Vaxlisp, Symbolics, TI, Franz,
and Xerox. Most implementations fail tests [A] and [C] part 1, but pass
tests [A] and [C] part 2; this is a consequence of implementing the
distinction between "for declaration" and "for discrimination". Lucid
and Xerox both pass test [B], and the other implementations fail it.
The Explorer returns NIL for all six tests in [A], [B], and [C].
Allegedly, the PCLS implementation does no "upgrading"; each array
"remembers" exactly the type-specifier handed to the MAKE-ARRAY call
that created it. Thus the test cases are not applicable to PCLS,
since the precondition cannot be met (i.e., find two non-type-equivalent
type-specifiers that are non-trivially upgraded by make-array).
The TI Explorer offers specialized representation for complexes;
part types of SINGLE-FLOAT and DOUBLE-FLOAT are specialized.
Cost to Implementors:
This proposal is an incompatible change to the current language
specification, but only a small amount of work should be required in
each vendor's implementation of TYPEP and SUBTYPEP.
Cost to Users:
Because of the prevalence of confusion in this area, it seems unlikely
that any user code will have to be changed. In fact, it is more likely
that some of the vendors will cease to get bug reports about MAKE-ARRAY
returning a result that isn't of "the obvious type". Since the change
is incompatible, some user code might have to be changed.
Cost of non-adoption:
Continuing confusion in the user community.
Benefits:
It will greatly reduce confusion in the user community. The fact that
(MAKE-ARRAY <n> :ELEMENT-TYPE '<type>) frequently is not of type
(ARRAY <type>) has been very confusing to almost everyone.
Portability of applications will be increased slightly, since
the behavior of
(TYPEP (MAKE-ARRAY <n> :ELEMENT-TYPE <type>) '(ARRAY <type>))
will no longer be implementation-dependent.
Esthetics:
Reducing the confusing distinction between type-specifiers "for
declaration" and "for discrimination" is a simplifying step -- it is a
much simpler rule to state that the type-specifiers actually describe
the collections of data they purport to name. Thus this is a step
towards increased elegance.
Discussion:
This issue was prompted by a lengthy discussion on the Common Lisp
mailing list. See for example a series of exchanges started on Thu,
17 Dec 87 10:48:05 PST by Jeff Barnett <jbarnett@nrtc.northrop.com>
under the subject line of "Types in CL". See also the exchange started
Wed, 6 Jan 88 23:21:16 PST by Jon L White <edsel!jonl@labrea.stanford.edu>
under the subject line of "TYPEP warp implications"
Although the types STRING, BIT-VECTOR, SIMPLE-STRING, and
SIMPLE-BIT-VECTOR are subtypes of the ARRAY type, they are not
specifically discussed in this proposal. The reason is that
they are not type-specifiers "that specialize", but are merely
abbreviations as follows:
STRING == (VECTOR STRING-CHAR)
SIMPLE-STRING == (SIMPLE-ARRAY STRING-CHAR (*))
BIT-VECTOR == (VECTOR BIT)
SIMPLE-BIT-VECTOR == (SIMPLE-ARRAY BIT (*))
Thus their semantics could be affected only in an implementation that
doesn't support a specific "specialized storage" type for arrays of
bits and vectors of string-chars. But in fact, every CL implementation
must appear to support "specialized storage" for bit-arrays and strings,
even if it means nothing more than remembering the fact that such an
array was created with that element-type. This is required in order
for strings, bit-vectors, and bit-arrays to be disjoint datatypes
(see CLtL p.34; see also the definitions of BIT-ARRAY and STRING found
in CLtL p.293, Section 17.4, and in CLtL p.299.)
We considered the possibility of flushing the permission to "upgrade";
for example, it could be made a requirement that:
(ARRAY-ELEMENT-TYPE (MAKE-ARRAY <n> :ELEMENT-TYPE <type>))
always be equal to <type> (or, at least type-equivalent to <type>)
for all valid type specifiers <type>. This has several problems: it
increases the storage requirement for many kinds of arrays, and hides
a relevant part of the underlying implementation for no apparently
good reason. However, it would increase portability, since it would be
much more difficult, for example, to write a program that created an
array with one element-type, say, (UNSIGNED-BYTE 5), but operated on it
assuming a non-trivial upgraded element-type, say, (UNSIGNED-BYTE 8).
Under this proposal, it is valid for an implementation of MAKE-ARRAY
to have arrays "remember" the type-equivalence class of the original
:element-type argument; such an implementation would satisfy all of
the constraints listed above.
We considered a suggestion to restrict the set of "known" array element
types; this would gain portability at the expense of limiting the
language.
We considered leaving out of the proposal the addition of the two
functions UPGRADED-ARRAY-ELEMENT-TYPE and UPGRADED-COMPLEX-PART-TYPE.
But it was noted that every implementation of CL supports exactly
that functionality somewhere in its implementation of MAKE-ARRAY; and
exposing this to the user would be a good thing. Furthermore, the
existence of at least UPGRADED-ARRAY-ELEMENT-TYPE makes the clarifications
on "upgrading" and SUBTYPEP implications easier. Finally, there would
be no other way at all to pinpoint just how complex parts are upgraded,
since there is no type information available except for the actual
types of the parts.
Since this proposal contains the implication:
(ARRAY <type1>) is-type-equivalent-to (ARRAY <type2>)
==>
<type1> is-type-equivalent-to <type2>
then the question naturally arises "Does the reverse implication hold?"
That is, should two non-EQ but type-equivalent type-specifiers <type1>
and <type2> always give rise to the same array types? For example,
consider SHORT-FLOAT and SINGLE-FLOAT in an implementation where these
are type-equivalent (see CLtL section 2.1.3). One may desire to implement
(ARRAY SHORT-FLOAT) and (ARRAY SINGLE-FLOAT) differently. Say, for example
that the former is packed into 16-bit half-words, whereas the latter is
packed into 32-bit words; but for either kind of packing, the result of
AREF is an ordinary "single-float". The whole point of the type-specifier
to make-array is merely to specify a packing technique for "packed float"
arrays. This "krinkle", however, will not be addressed by the proposal
herein; it should simply be remembered that the implication above goes
only one way, and is not an "if-and-only-if" link.
∂05-Dec-88 1238 X3J13-mailer Another Report on ISO/WG16
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 5 Dec 88 12:37:53 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA18474; Mon, 5 Dec 88 15:36:53 EST
Received: by mcvax.cwi.nl via EUnet; Mon, 5 Dec 88 18:44:17 +0100 (MET)
Received: by inria.inria.fr via Fnet-EUnet; Mon, 5 Dec 88 14:39:02 +0100 (MET)
Date: Mon, 5 Dec 88 12:03:36 -0100
From: mcvax!poly!queinnec@uunet.UU.NET (Queinnec Christian)
Message-Id: <8812051103.AA26857@poly.poly.fr>
To: rpg@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
Subject: Another Report on ISO/WG16
I just received your *personal* report on the last ISO meeting,
you sent to x3j13, and want to make some remarks to it. First, you
have the right to write anything you want, but the incriminated people
have also the right to try to present their own perception. You mix up
official stuff with personal or private thoughts aiming, in my own
point of view, to confusion. I will then try to fix, as the convenor
of the WG16, some of the points you made.
> The French Delegation consisted of Jerome Chailloux and Greg Nuyens.
> They responded by remarking that the US position represented a
> ``preposterous'' change in position by the US and directly
> contradicted the agreed-upon work item. This work item was the AFNOR...
No! The New Work Item was the result of an international agreement
which still remains unaltered.
> ... (French) position which was to standardize a Common-Lisp-like dialect
> with no packages, simple lambda-lists, simple arrays, generic
> functions without classes, a different multiple value system, and a
> different syntax for specials.
This list of technical points was decided in Paris Meeting as a way to
proceed to standardize IsLisp on the basis of CLtL as already improved
by X3J13. As every technical point in the agenda, it can be discussed
at length or even reassessed (as in Snowbird).
> The US argued that this plan was never
> voted on because the convener would not allow it: He exaplined that
> because it was a technical proposal, it was subject to discussion as
> are all other technical points.
See above.
> The US further remarked that the US position allowed for multiple
> standardized dialects, but the convener denied this was possible under
> the current work item and suggested we could try introducing a second
> work item.
I continue to interpret the NWI as a chart to standardize only one
element of the Lisp family.
> The French delegation contended that the US plan was to block the ISO
> process. They were right in the limited sense that I threatened to
> block the standardization of any dialect of Common Lisp that was
> neither a superset nor a subset of Common Lisp.
> I should point out that the French have formally asked SC22 (the
> parent group of WG16) whether naming the resulting dialect ``IsLisp''
> was allowed because the original work item stated that a standard for
> ``Lisp'' was being produced. The French commented that the US voted
> ``yes'' on the work item and that our comment about the name was
> irrelevant.
The US comment (like any other comment) is not irrelevant. But since it
would be the first time that a language would be standardized under a
precise name and not its proper name, this proposal as well as the
name voted in the WG were submitted, not to SC22, but to ISO in Geneva.
> Jerome Chailloux's company, ILOG, has a contract from
> ESPRIT to produce a draft of ``ISO Lisp.'' In fact, an ESPRIT catalog
> we saw stated that the draft had been produced by ILOG in 1987 and was
> available on request. However, to our knowledge, there is no ESPRIT
> draft document of ``ISO Lisp''. All documents produced by AFNOR and
> ILOG refer to ``ISO Lisp.''
In the AFNOR documents as well as in the BSI documents, the `Lisp'
to be standardized in the WG is nicknamed 'ISO Lisp'. Until a formal
agreement by ISO of the name IsLisp, this one is sufficiently clear
as were ISO Pascal, ANSI C...
> As an aside, Chailloux pointed out that he oversees a lot of the
> ESPRIT work on AI and that he would not allow any contractor to
> use Common Lisp, only ISO Lisp. ILOG advertizes that ISO Lisp will
> be available in the first half of 1989 (Beta available in December).
> He told Dussud that he would ``have the Germans back in line by
> December 15'' (which is the next EuLisp meeting).
Is this a personal thought of Mr Richard P. Gabriel about Mr Jerome Chailloux ?
> The convener declared that discussion on this topic was deadlocked
> until AFNOR...
and BSI and Netherlands and other countries not present. I recall that
the precise topic debated here is related to the answer of the WG to
the proposed US resolution.
>... could meet to decide their response to the US and German
> position statements, which would not be until after the Hawaii
> meeting. However, the convener told Mathis in private that he did not
> want to go to Hawaii and was trying to find a way to cancel the
> meeting.
It probably would have been the case that I cannot attend the Hawaii
meeting (due to lack of funds) but this is not a reason to cancel
it: first, the secretary would have been there and second, I can
mandate someone to represent me at this precise meeting as currently
done in other WGs.
> The convener also threatened to report failure to SC22 based
> on his opinion that a consensus is not possible.
I was mandated by SC22 to lead the standardization work. In case of
failure i.e, if I fail to reach a consensus, I naturally have to
report it to SC22.
> The US delegation agreed to ask X3J13 and the IEEE Scheme groups
> whether they were willing to submit drafts under the German proposal.
> While so agreeing, we pointed out that the convener was acting as if
> the German position would be accepted. I pointed out that the US had
> not withdrawn its proposed resolution.
It is true that everybody acts as if the German point of view was the
main topic to be discussed. I guess it is a consensus ...
C.Queinnec
Convenor of the WG16.
∂05-Dec-88 1240 LOGMTC-mailer seminar reminder
To: logmtc@SAIL.Stanford.EDU
From: Carolyn Talcott <CLT@SAIL.Stanford.EDU>
Speaker: Yukiyoshi Kameyama (Tohoku University)
(visiting Stanford 27 Nov to 16 Dec)
Title: Programming/Proving System in SST
(Joint work with Prof. Masahiko Sato.)
Time: 11am, Tuesday December 6, 1988
Place: 352 Margaret Jacks Hall, Stanford
Abstract:
We are mainly interested in developing a proving/programming
system on computer. To do so, we present a functional programming
language Lambda and a constructive logical system SST, Symbolic
Set Theory. Lambda is intended to be an object language and a
meta language of SST; Namely, a Lambda program is verified in
SST naturally (since a Lambda program is just a closed term in SST),
and at the same time, a proof-system of SST will be implemented
on top of Lambda. We, then, will be able to prove the correctness
of the proof-system using the system itself, and some meta-theorems
within SST.
∂05-Dec-88 1249 X3J13-mailer Issue: CLOSED-STREAM-OPERATIONS (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Dec 88 12:48:03 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 05 DEC 88 12:25:45 PST
Date: 5 Dec 88 12:25 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: CLOSED-STREAM-OPERATIONS (Version 4)
To: X3J13@sail.stanford.edu
From: CL-CLEANUP@Sail.Stanford.Edu
Reply-to: CL-CLEANUP@Sail.Stanford.Edu
cc: Masinter.pa@Xerox.COM
Line-fold: NO
Message-ID: <881205-122545-3938@Xerox>
Some parts of the original issue were separated out as we have
not yet arrived at a recommendation.
!
Forum: Cleanup
Issue: CLOSED-STREAM-OPERATIONS
References: CLOSE (CLtL p 332)
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
8-Oct-88, Version 2 by Masinter
13-Oct-88, Version 3 by van Roggen
1-Dec-88, Version 4 by Pitman
5-Dec-88, Version 5 by Masinter (separate other issues)
Related Issues: STREAM-ACCESS, STREAM-INFO, INPUT-STREAM-P-CLOSED,
CLOSE-CONSTRUCTED-STREAMS, PATHNAME-STREAM
Problem Description:
The description of CLOSE is not completely clear about the functions
which are allowed to be performed on a closed stream.
On p332 it says:
``The stream is closed. No further Input/output operations may be
performed on it. However, certain inquiry operations may still
be performed, ...''
but the list of inquiry operations is not specified.
Proposal (CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY)
Clarify the behavior of the following functions on closed streams:
* STREAMP is unaffected by whether its stream argument is open or closed.
* If CLOSE is called on a stream which is open, it will return T.
However, if CLOSE is called on a stream which is closed, it
will succeed without error but the return value is not specified.
* PATHNAME is valid on either an open or closed stream. Since some
implementations cannot provide the truename of a file until the
file is closed, it would in principle be possible for PATHNAME in
some implementations to return more specific information after the
stream is closed. For consistency, however, PATHNAME is prohibited
from doing this. PATHNAME must return the same pathname after a
file is closed as it did before. (The passed proposal in issue
PATHNAME-STREAM still stands.)
* TRUENAME is valid on either an open or closed stream. Since some
implementations cannot provide the truename of a file until the
file is closed, it is permissible TRUENAME to return more specific
information after the stream is closed.
* MERGE-PATHNAMES, PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY,
PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION, NAMESTRING,
FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING,
ENOUGH-NAMESTRING, and OPEN are valid on either open or closed streams.
For any of these operations, using a stream, S, as an argument
where appropriate is equivalent to using (PATHNAME s). See the
description of PATHNAME above to understand the consequences of this.
* PROBE-FILE and DIRECTORY are valid on either open or closed streams.
For either of these operations, using a stream, S, as an argument
where appropriate is equivalent to using (PATHNAME s). See the
description of PATHNAME above to understand the consequences of this.
In this case of these operators however, closed stream may well be the
most reliable arguments in some cases, since treatment of open streams
to the file system may vary considerably between implementations.
For example, in some operating systems, open files are written under
temporary names and not renamed until close and/or are held invisible
until a close is performed. In general, any code with an intent to be
highly portable should tread lightly when using PROBE-FILE or
DIRECTORY.
Rationale:
One can consider many characteristics of a stream to be independent of
the ability to do I/O. Being able to determine a stream's direction and
its name is often useful for debugging. A number of the descriptions in
CLtL imply (weakly) the ability to work on closed streams. Functions
such as OPEN and DIRECTORY don't really depend on the stream, but on
the name of the stream.
Current Practice:
At least two implementations differ in which functions are allowed to be
performed on a closed stream.
Cost to Implementors:
Unknown, but likely to be small in most implementations.
A nontrivial amount of work may be necessary if the pathname information
is held externally and is normally deleted when the stream is closed.
The implementation will have to copy the information at some time for later
inquiries.
Cost to Users:
Likely to be small; users of an implementation forced to change
by this proposal might have to make some modifications to make their
programs portable.
Benefits:
These clarifications will assist users in writing portable code.
Aesthetics:
Most people will probably see these clarifications as an improvement
in aesthetics.
Discussion:
There are some separate, but related, issues regarding what CLOSE
should do on composite streams or constructed streams such as
created by MAKE-BROADCAST-STREAM. These issues will be addressed
in a separate issue (CLOSE-CONSTRUCTED-STREAMS).
There was some discussion on whether INPUT-STREAM-P and OUTPUT-STREAM-P
should return "false" on a stream that had been closed. The issue
STREAM-ACCESS contains a proposal to add a function OPEN-STREAM-P
which might be useful for the same purpose. This issue was separated
out into a separate issue (INPUT-STREAM-P-CLOSED).
The other functions in proposal STREAM-ACCESS:PROVIDE should
work on closed streams.
The functions in STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS should
not be requred to work on closed streams.
∂05-Dec-88 1350 BSCOTT@Score.Stanford.EDU ID Cards
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Dec 88 13:50:39 PST
Date: Mon 5 Dec 88 13:48:48-PST
From: Betty Scott <BSCOTT@Score.Stanford.EDU>
Subject: ID Cards
To: AC@Score.Stanford.EDU
cc: BScott@Score.Stanford.EDU
Message-ID: <12452078261.18.BSCOTT@Score.Stanford.EDU>
If you did not receive a new Stanford ID card, please let me know. The old
ones expired 11/88.
Betty
-------
∂05-Dec-88 1408 BSCOTT@Score.Stanford.EDU ID Cards--Sorry
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Dec 88 14:08:25 PST
Date: Mon 5 Dec 88 14:07:31-PST
From: Betty Scott <BSCOTT@Score.Stanford.EDU>
Subject: ID Cards--Sorry
To: AC@Score.Stanford.EDU
cc: BScott@Score.Stanford.EDU
Message-ID: <12452081666.18.BSCOTT@Score.Stanford.EDU>
My message should have stated that Computer Science faculty missing ID cards
should let me know.
Betty
-------
∂05-Dec-88 1429 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Lunch with Jim Gibbons
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Dec 88 14:29:23 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 5 Dec 88 14:26:38-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA07287; Mon, 5 Dec 88 14:26:10 PDT
Date: Mon, 5 Dec 88 14:26:10 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8812052226.AA07287@Tenaya.stanford.edu>
To: faculty@score
Subject: Lunch with Jim Gibbons
Jim Gibbons is one of our most enthusiastic backers among the
higher administration. Earlier in the year he expressed a wish
for more contact with faculty in the SOE, and our faculty lunch
tomorrow will give him a chance to talk with us. Come ask him
anything you want. -Nils
∂05-Dec-88 1531 X3J13-mailer Issue: DECLARE-FUNCTION-AMBIGUITY (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Dec 88 15:30:53 PST
Received: from Semillon.ms by ArpaGateway.ms ; 05 DEC 88 15:25:23 PST
Date: 5 Dec 88 15:25 PST
Sender: masinter.pa@Xerox.COM
To: X3J13@sail.stanford.edu
From: CL-CLEANUP@Sail.stanford.edu
REPLY-TO: CL-CLEANUP@sail.stanford.edu
Subject: Issue: DECLARE-FUNCTION-AMBIGUITY (version 3)
cc: masinter.pa@Xerox.COM
Message-ID: <881205-152523-4432@Xerox>
!
Forum: Cleanup
Issue: DECLARE-FUNCTION-AMBIGUITY
References: CLtL pp 43 (Table 4-1), 158-159
Issue FUNCTION-TYPE (passed X3J13/June 1988)
Category: CHANGE
Edit history: #1, 21 Sept 1988, Walter van Roggen
#2, 29 Sept 1988, Walter van Roggen (renamed; lessened ambiguity)
#3, 30-Sep-88, Masinter
#4, 5-Dec-88, Masinter (append Oct x3j13 comments)
Problem description:
CLtL permits confusing and ambiguous FUNCTION declarations. One can say
(DECLARE (FUNCTION F (VECTOR INTEGER) T))
to indicate that the function binding for F is of a certain type. Yet
one can also say
(DECLARE (FUNCTION X Y Z))
to indicate that the variables X, Y, and Z have values which are functions.
The former is an abbreviation for
(DECLARE (FTYPE (FUNCTION (VECTOR INTEGER) T) F))
The latter is an abbreviation for
(DECLARE (TYPE FUNCTION X Y Z))
The ambiguity arises in a case like
(DECLARE (FUNCTION F NIL STRING))
However, it would be an error to declare the type of the constant NIL to be a
FUNCTION, so technically there is no ambiguity--there is just a peculiar
special case.
Using the same declaration for two completely different purposes can lead
to confusion among people writing or reading such code.
It is now more useful to declare that variables have a value which
is of type FUNCTION, since the type FUNCTION has a more well-specified
meaning.
Proposal (DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION)
The declaration (FUNCTION name argtypes valtypes) is no longer permitted
to be an abbreviation for (FTYPE (FUNCTION argtypes valtypes) name).
The declaration (FUNCTION var1 var2) would just be an abbreviation for
(TYPE FUNCTION var1 var2).
Rationale:
Continuing to allow all the predefined atomic type specifiers as declaration
abbreviations for (TYPE type var1 var2 ...) is simpler for users to understand.
In other words, all the normal type declarations describe variable bindings;
only the FTYPE declaration describes function bindings. This is a more
uniform solution than making an exception to table 4-1.
Since the old use of the FUNCTION declaration for function bindings was just
an abbreviation for the FTYPE declaration, no expressivity is lost.
Furthermore one is able to say that a variable's value is of type FUNCTION,
something that hadn't been clearly possible without using the TYPE declaration.
Current Practice:
Many current implementations treat FUNCTION declarations
only as abbreviations for FTYPE declarations, primarily because
the proposal FUNCTION-TYPE has not been widely implemented.
Cost to Implementors:
Likely to be small to those implementations that heed these kinds of
declarations; none for those that don't.
Cost to Users:
Existing uses of the FUNCTION declaration for function bindings will need
to be changed to FTYPE declarations.
Cost of Non-Adoption:
People will continue to be confused by function declarations.
Benefits:
A simpler language.
Esthetics:
Discussion:
Making it clear that only FTYPE declarations describe function bindings will
make it easier to add new kinds of declarations that support incremental or
additional descriptions, as is needed for describing methods.
Since all cases can be disambiguated after all, compatibility considerations
might deem this proposal to be unnecessary. However, making declarations
simpler and less confusing is possibly more important than compatibility.
There is no consensus on the cleanup committee.
Comments from October 1988 X3J13 meeting:
... opposed but not vehemently--the incompatible change is gratuitous
... prefer to document the
issue rather than change it."
... a number of implementations accidentally implement
this incorrectly. They first check the type table and then handle
the elaborate function declaration style. But, as it happens,
they never reach the code for the second case because function is
in the type table!
... Having both styles is worse than having either one or the other.
∂05-Dec-88 1641 X3J13-mailer Issue: DEFPACKAGE (Version 7)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Dec 88 16:41:24 PST
Received: from Semillon.ms by ArpaGateway.ms ; 05 DEC 88 16:39:43 PST
Date: 5 Dec 88 16:39 PST
Sender: masinter.pa@Xerox.COM
to: X3J13@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
Subject: Issue: DEFPACKAGE (Version 7)
reply-to: CL-CLEANUP@Sail.stanford.edu
Message-ID: <881205-163943-4628@Xerox>
!
Issue: DEFPACKAGE
References: CLtL section 11.7.
Issue: IN-PACKAGE-FUNCTIONALITY
Issue: MAKE-PACKAGE-USE-DEFAULT
Issue: PACKAGE-DELETION
Category: ADDITION
Edit history: Version 1, 12-Mar-88, Moon
Version 2, 23-Mar-88, Moon, changes based on discussion
Version 3, 27-Sep-88, JonL
(remove :import, :shadowing-import; allow :export to work on
imported and inherited; update references to in-package, etc.)
Version 4, 1-Oct-88, Masinter
Version 5, 6-Oct-88, Moon
Version 6, 6-Oct-88, JonL (little nits)
Version 7, 2-Nov-88, JonL
(incorporate further discussion; simplify handling of
syntactic errors; specify ordering constraints).
Problem description:
Many users incorrectly think that package operations can be performed
in any order. CLtL (p.192) contributes to this misconception.
Programmers need direction on the ordering constraint, especially for
creating packages, since doing things out of order can lead to
confusing or even intractable problems.
If the definition of a package is scattered throughout a program as a
number of individual forms, it is very easy to read a symbol before the
package setup needed to read that symbol correctly has been accomplished.
Three examples: an inherited symbol that should have been shadowed might
be accessed; a single-colon prefix might be used for a symbol that hasn't
yet been exported; an internal symbol might be created afresh where a
symbol that will later be imported or inherited was intended. These
problems can be difficult to understand or even to recognize; in some
cases it is difficult or impossible to correct the situation in the
same Lisp image.
Proposal (DEFPACKAGE:ADDITION):
Add a DEFPACKAGE macro to the language. In the description below,
'package-name' and 'symbol-name' can be a symbol or a string; if a
symbol, only its name matters, not what package it is in.
The syntax of DEFPACKAGE is
(DEFPACKAGE package-name {option}*)
where each option is a list of a keyword and arguments. Nothing in a
DEFPACKAGE form is evaluated.
Standard options for DEFPACKAGE are listed below. Except for :SIZE,
options may appear more than once (this is useful primarily for
:IMPORT-FROM and :SHADOWING-IMPORT-FROM).
(:NICKNAMES {package-name}*)
Set the package's nicknames to the specified names.
(:USE {package-name}*)
The package is to "use" the other designated packages; that is,
it will inherit from them. The default value for this option
should be the same as it is for MAKE-PACKAGE (also see the issue
MAKE-PACKAGE-USE-DEFAULT).
(:SHADOW {symbol-name}*)
Create the specified symbols in the package being defined,
making them shadows, just as the function SHADOW would do.
(:SHADOWING-IMPORT-FROM package-name {symbol-name}*)
Find the specified symbols in the specified package, import
them into the package being defined, and place them on the
shadowing symbols list. In no case will symbols be created in
any package other than the one being defined; a continuable error
is signaled if no symbol is accessible in the package named
package-name for one of the symbol-names.
(:IMPORT-FROM package-name {symbol-name}*)
Find the specified symbols in the specified package and import
them into the package being defined. In no case will symbols be
created in a package other than the one being defined; a continuable
error is signaled if no symbol is accessible in the package named
package-name for one of the symbol-names.
(:EXPORT {symbol-name}*)
Find or create symbols with the specified names and export them.
Note an interaction with the :USE option, since inherited symbols
can be used rather than new ones created; note also an interaction
with the :IMPORT-FROM and :SHADOWING-IMPORT-FROM options, since
imported symbols can be used rather than new ones created.
(:INTERN {symbol-name}*)
Find or create symbols with the specified names. Note an
interaction with the :USE option, since inherited symbols
can be used rather than new ones created. This option is useful if
an :IMPORT-FROM or a :SHADOWING-IMPORT-FROM option in a subsequent
call to DEFPACKAGE (for some other package) expects to find these
symbols accessible but not necessarily external.
(:SIZE integer)
Declare the approximate number of symbols expected in the package.
This is an efficiency hint only, so that the package's table will
not have to be frequently re-expanded when new symbols are added
to it (e.g., by reading in a large file "in" that package).
The order in which the options occur in a DEFPACKAGE form is irrelevant;
but since the effects of the entry-making options are context-sensitive,
the order in which they will be executed is as follows:
(1) :SHADOW and :SHADOWING-IMPORT-FROM
(2) :USE
(3) :IMPORT-FROM and :INTERN
(4) :EXPORT
Shadows are established first, since they may be necessary to block
spurious name conflicts when the use link is established. Use links are
established next so that :intern and :export may refer to normally
inherited symbols. The :export is done last so that it may refer to
symbols created by any of the other options; in particular, shadows and
imported symbols can be made external. Note also the prescription on CLtL
p.178 to cover the case of calling EXPORT on an inherited symbol.
DEFPACKAGE creates the package as specified and returns it as its value.
It has no other side effects; e.g., it does not alter the value of *PACKAGE*.
The function COMPILE-FILE should treat top-level DEFPACKAGE forms the
same way it treats the other package-effecting functions (see CLtL p.182).
If the specified name already refers to an existing package, then the
name-to-package mapping for that name is not changed. At most, the
existing package will be modified to reflect the new definition; it is
undefined what happens if the new definition is at variance with the
current state of that package. If one of the specified nicknames already
refers to an existing package, then an error is signaled just the same
as MAKE-PACKAGE would. See the issue PACKAGE-DELETION for undoing the
name-to-package mapping.
Some DEFPACKAGE errors are, however, purely syntactic.
(1) An error should be signaled if :SIZE appears than once.
(2) Since extended options might be allowed by other implementations,
an error should be signaled if an option is present that is not
actually supported in this implementation.
(3) The collection of symbol-name arguments given to the options
:SHADOW, :INTERN, :IMPORT-FROM, and :SHADOWING-IMPORT-FROM must
all be disjoint; additionally, the symbol-name arguments given to
:EXPORT and :INTERN must be disjoint. If either condition is
violated, an error should be signaled.
Name conflict errors will, of course, be handled by the underlying calls to
USE-PACKAGE, IMPORT, and EXPORT.
Examples:
;;; An example that "plays it super-safe" by using only strings as names;
;;; does not even assume that the package it is read in to "uses" LISP;
;; *never* creates any symbols whatsoever in the package that it is read
;; in to.
(LISP:DEFPACKAGE "MY-PACKAGE"
(:NICKNAMES "MYPKG" "MY-PKG")
(:USE "LISP")
(:SHADOW "CAR" "CDR")
(:SHADOWING-IMPORT-FROM "VENDOR-COMMON-LISP" "CONS")
(:IMPORT-FROM "VENDOR-COMMON-LISP" "GC")
(:EXPORT "EQ" "CONS" "FROBOLA")
)
;;; A similar call, mostly using symbols rather than strings as names.
;;; Expects to be read in to a package that "uses" LISP and *may* create
;;; random internal symbols in that package (such as MY-PACKAGE etc).
(defpackage my-package
(:nicknames mypkg :MY-PKG) ;remember CL conventions for case
(:use lisp) ; conversion on symbols
(:shadow CAR :cdr #:cons)
(:export "CONS") ;yes, this is the shadowed one.
)
Rationale:
The availability of DEFPACKAGE encourages putting the entire package
definition in a single place. It also encourages putting all the package
definitions of a program in a single file, which can be loaded before
loading or compiling anything else that depends on those packages; such a
file can be read in the USER package, avoiding any initial state issues.
In addition, DEFPACKAGE allows a programming environment to process
the whole package setup as a unit, providing better error-checking and
more assistance with package problems, by dint of global knowledge of
the package setup.
Current practice:
Symbolics Common Lisp (SCL) has always had a DEFPACKAGE, and users
prefer it to individual calls to EXPORT, IMPORT, SHADOW, etc. The SCL
version of DEFPACKAGE has quite a few additional options, but none of
them appears to be necessary to propose for Common Lisp at this time.
This proposal is incompatible with Symbolics DEFPACKAGE in some ways
that will probably not cause major problems.
Cost to Implementors:
Small--DEFPACKAGE can be implemented simply as a bunch of
calls to existing functions.
Cost to Users:
Small, this is upward compatible.
Cost of non-adoption:
Packages continue to be difficult to use correctly.
Benefits:
Guide users away from using packages in ways that get them into trouble.
Esthetics:
Neutral.
Discussion:
It has been suggested that the "Put IN Seven EXtremely Random USEr
Interface COmmands" mnemonic described in CLtL p.191 could be removed;
and with possibly a few exceptions, the special handling of them by
COMPILE-FILE could be removed. As this would be an incompatible change,
it is not part of this proposal. However, a new mnemonic can be offered,
to help remember the ordering constraints mentioned above:
I REmember Six USEr Interface Expressions
Each word in the sentence corresponds to one operation listed below:
I IN-PACKAGE ;"foot" to stand on
REmember REQUIRE ;ensure pre-requisite packages
Six SHADOW ;block multiple-inheritances
USEr USE-PACKAGE ;go for it!
Interface IMPORT ;bring in "foreign" symbols
EXpressions EXPORT ;a "face" to show to others.
It is noted that DEFPACKAGE cannot be used to create two "mutually
recursive" packages, such as:
(defpackage my-package
(:use lisp your-package) ;requires 'your-package' to exist first
(:export "MY-FUN"))
(defpackage your-package
(:use lisp)
(:import-from my-package "MY-FUN") ;requires 'my-package' to exist first
(:export "MY-FUN"))
However, nothing prevents one from using the package-effecting functions
such as USE-PACKAGE, IMPORT, and EXPORT to establish such links (which
ought to be very rare) after a more standard use of DEFPACKAGE.
The macroexpansion of DEFPACKAGE could usefully canonicalize the names
into strings, so that even if a source file has random symbols in the
DEFPACKAGE form, the compiled file would only contain strings.
Frequently additional implementation-dependent options take the
form of a keyword standing by itself as an abbreviation for a list
(keyword T); this syntax should be properly reported as an unrecognized
option in implementations that do not support it.
Definition forms in Common Lisp usually just establish a name-to-object
mapping; there is little precedent for them to modify other global-context
state. For this reason, we didn't want DEFPACKAGE also to "go" into the
new package. If it did so, like IN-PACKAGE, then the following reasonable
file would become confused, because it wouldn't all be in one package:
(in-package "USER")
(defpackage "WATER" (:use "LISP") (:export "FISH"))
(defpackage "ALCHEMY" (:use "LISP" "PHLOGISTON) (:export gold))
Should the token 'gold' be read while in the USER package, or in the
the WATER package?
The issue IN-PACKAGE-FUNCTIONALITY recommends that IN-PACKAGE be
incompatibly changed to recognize only existing packages, not to create
them. IN-PACKAGE would then not accept any keyword arguments.
The function MAKE-PACKAGE might also be extended to take all the keywords
that DEFPACKAGE does. This could be the subject of a separate cleanup.
∂06-Dec-88 0810 X3J13-mailer Re: ISO meeting report
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 6 Dec 88 08:10:08 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA08575; Tue, 6 Dec 88 08:12:45 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA01763; Tue, 6 Dec 88 08:09:24 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA08992; Tue, 6 Dec 88 08:09:57 PST
Message-Id: <8812061609.AA08992@suntana.sun.com>
To: rpg@sail.stanford.edu,
mcvax!inria.inria.fr!chaillou@uunet.UU.NET (Jerome Chailloux)
Cc: x3j13@sail.stanford.edu
Subject: Re: ISO meeting report
In-Reply-To: Your message of Sat, 03 Dec 88 00:19:19 +0100.
<8812022319.AA10635@inria.inria.fr>
Date: Tue, 06 Dec 88 08:09:54 PST
From: kempf@Sun.COM
We are disappointed by the apparent disarray in relations between
ISO and ANSI and that there will not be a joint meeting
in January.
We believe that it is important to continue research into Lisp language
semantics which differ from those of Common Lisp, especially in areas
where Common Lisp is weak. The results of such research, once they become
accepted practice, can often be fed back into the standardization process,
strengthening the technical base of the standard. But standardization efforts
are not the place for research.
The position in the US statement reflects pretty much
the state of industry with regard to the commercialization of Lisp.
There is not really any demand for a commercial Lisp other than Common
Lisp in the US at the moment. Since Sun, as is the case for other Lisp vendors,
operates in the international marketplace, an international standard for
Common Lisp is highly desirable, since it reduces the investment Sun needs
to make in developing and supporting Lisp and Lisp based tools. Nobody
here believes that Common Lisp is technically the "right" solution, but
the technical challenges facing commercial Lisp today are less in terms
of semantics and more in terms of implementation technology. We expect
to monitor developments in Scheme and ISO activity.
We hope that the ANSI/ISO split can be resolved as quickly as possible, so
that the enormous amount of work put into the Common Lisp standard by
X3J13 over the last 3 years can benefit the international Lisp community
as well, and that the technical expertese of the international Lisp
community can be brought to bear on the final stages of checking the
draft standard for correctness.
James Kempf, Sun Microsystems
Cris Perdue, Sun Microsystems
∂06-Dec-88 1031 debra@russell.Stanford.EDU REMINDER
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Dec 88 10:31:20 PST
Received: from localhost by russell.Stanford.EDU (4.0/4.7); Tue, 6 Dec 88 10:33:16 PST
To: evesem@russell.Stanford.EDU
Cc: debra@russell.Stanford.EDU, kuder@russell.Stanford.EDU
Subject: REMINDER
Date: Tue, 06 Dec 88 10:33:14 PST
From: Debra Alty <debra@russell.Stanford.EDU>
REMINDER
The next EVENING SEMINAR will be Wednesday, December 7th @ 7:30 pm in
the CSLI Cordura Conference Room.
Professor Ivan Sag, Linguistics Department, will be leading this
evening's discussion.
The following will be served:
Pate Cognac
Breads & Crackers Wine
Vegetable platter Sparkling Waters
w/dip Coffee
Petit Fours Tea
∂06-Dec-88 1109 @Score.Stanford.EDU:wheaton@athena.stanford.edu GIS programs
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Dec 88 11:09:30 PST
Received: from athena.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 6 Dec 88 11:06:04-PST
Received: by athena.stanford.edu (5.59/25-eef) id AA25358; Tue, 6 Dec 88 11:06:13 PDT
Date: Tue, 6 Dec 88 11:06:13 PDT
From: George Wheaton <wheaton@athena.stanford.edu>
Message-Id: <8812061906.AA25358@athena.stanford.edu>
To: faculty@score
Subject: GIS programs
Yesterday, I received a call from Alan Grundmann, the Administrative
Director of Jasper Ridge. He asked if anyone if CSD is familiar with
a database location and mapping program known as GIS (Graphic
Information System). ESRI, a company in Southern California, markets
a GIS program under the name of Arcinfo. Apparently, the structure of
the program allows it to be used for a variety of applications, not
just mapping physical terrain. If anyone knows anything about the
program, please let me know,and I'll pass the information on to Alan.
Thanks,
gw
∂06-Dec-88 1144 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu party
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Dec 88 11:44:28 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 6 Dec 88 11:37:10-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA07853; Tue, 6 Dec 88 11:36:37 PDT
Date: Tue, 6 Dec 88 11:36:37 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8812061936.AA07853@Tenaya.stanford.edu>
To: faculty@score
Subject: party
Invitations will soon go out. This is a "calendar advisory"
to save the date:
OPEN HOUSE FOR CSD FACULTY, SENIOR STAFF, AND SENIOR RESEARCH
ASSOCIATES and friends at the Nilssons on Sunday, January 1, 1989 3-8
pm.
-Nils
∂06-Dec-88 1336 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu position available
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Dec 88 13:36:47 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AB00229; Tue, 6 Dec 88 13:36:22 PDT
Message-Id: <8812062136.AB00229@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 6 Dec 88 13:19:49 PST
Received: by BYUADMIN (Mailer R2.01) id 4509; Tue, 06 Dec 88 14:17:51 MST
Date: Tue, 6 Dec 88 15:13:49 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
lescanne%POINCARE.CRIN.FR@Forsythe.Stanford.EDU
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: lescanne%POINCARE.CRIN.FR@Forsythe.Stanford.EDU
Subject: position available
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
POSITION OF VISITING PROFESSOR AVAILABLE
The university of Nancy has a position of visiting professor available
for 1989. This person will be able to work for her (his) research at
Centre de Recherche en Informatique de Nancy and/or at INRIA-Lorraine.
For mor information send me computer mail.
Pierre LESCANNE
Centre de Recherche en Informatique de Nancy
telephone: 83 91 21 19 (country code is 33)
e-mail: lescanne@poincare.crin.fr
post: BP 239, F54506 VANDOEUVRE Cedex FRANCE
∂06-Dec-88 1343 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu communication delays (was analysis of parallel algorithms)
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Dec 88 13:43:44 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA00789; Tue, 6 Dec 88 13:43:17 PDT
Message-Id: <8812062143.AA00789@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 6 Dec 88 13:43:54 PST
Received: by BYUADMIN (Mailer R2.01) id 4909; Tue, 06 Dec 88 14:41:36 MST
Date: Tue, 6 Dec 88 15:17:56 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Douglas Jones <jones%HERKY.CS.UIOWA.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Douglas Jones <jones%HERKY.CS.UIOWA.EDU@Forsythe.Stanford.EDU>
Subject: communication delays (was analysis of parallel algorithms)
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
In Hai-Ning Liu's theorynet note of Dec. 5, 1988, he asks:
> I am interested in results about communication delay between any two
> processors. Note this is different from PRAM model.
I have long suspected that there is a natural law that communication delays
in a system with n components are O(log n). As a proposed natural law, this
is subject to counterexample and refinement, but cannot be proven.
Note that most Parallel Random Access Memory models assume that access time
is constant, independent of memory size and number of processors, but that
real parallel random access memory cannot be built this way. To see this,
imagine any fixed technology. All known technologies build memory from
modules with a fixed capacity per module. Even if there is only one processor,
that processor must have a way to send memory addresses and data to all of the
modules. All known technologies have a limit on the fanout allowed on any
signal. If there are more modules than this fanout limit, some kind of
repeaters or amplifiers must be used. Say the fanout limit allows a maximum
of k modules to listen to any signal. In general, this requires a k-ary tree
of amplifiers to take address or data signals from the processor to memory.
For a sufficiently large memory, the delays involved in this k-ary tree will
dominate the memory access time, so we have O(log n) access, with logarithms
to the base k.
A similar argument applies to the data path from memory to processors, but
here, the problem is the limited fanin of feasible multiplexors, with the
result that a multiplexor tree is needed to bring signals from modules to the
processor.
Similar arguments apply to n processors sharing one memory, and these arguments
directly underly the design of the butterfly switch.
In multiprocessor systems with message passing, one can make similar arguments
about the message routing hardware.
Note that all of these arguments rest on the key statement "All known
technologies". I know of no way to prove that someone tommorow cannot find a
new technology that evades these limits; such a new technology might, after-all
rest on now unknown physical principles. At this point, a digression into the
realm of Karl-Popper is appropriate, but not in this newsgroup.
Douglas Jones
jones@herky.cs.uiowa.edu
∂07-Dec-88 0815 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Communications Complexity
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Dec 88 08:15:31 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA15760; Wed, 7 Dec 88 08:15:10 PDT
Message-Id: <8812071615.AA15760@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 7 Dec 88 08:15:47 PST
Received: by BYUADMIN (Mailer R2.01) id 2783; Wed, 07 Dec 88 09:13:55 MST
Date: Wed, 7 Dec 88 10:05:31 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Juergen Doenhardt <juergen%PBINFO.UNI-PADERBORN.DE@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Juergen Doenhardt <juergen%PBINFO.UNI-PADERBORN.DE@Forsythe.Stanford.EDU>
Subject: Communications Complexity
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
In theorynet mails due to Hai-Ning Liu and Douglas Jones it is
discussed if one can prove lower bounds for the (communication) delay
of circuits that incorporate all "possible" technologies. For a somewhat
restricted situation, bounds for that delay are given in Paul's book on
complexity theory
(Paul, Komplexitaetstheorie, Teubner, West Germany, 1978)
using "hard physics" (Heisenberg's relation, gravity fields and such).
Juergen Doenhardt
∂07-Dec-88 0946 STAGER@Score.Stanford.EDU Grade Sheets
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Dec 88 09:46:40 PST
Date: Wed 7 Dec 88 09:44:24-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: Grade Sheets
To: faculty@Score.Stanford.EDU
cc: stager@Score.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12452558057.24.STAGER@Score.Stanford.EDU>
Grade sheets have arrived and will be distributed shortly. Deliveries will
be made by courier to mailboxes later today. Please let me know if you
haven't recieved your grade sheets by Friday (December 9).
RETURN COMPLETED GRADE SHEETS TO CS-TAC BY NOON MONDAY, DECEMBER 19!!!
Thanks again.
Claire
-------
∂07-Dec-88 1153 misha@polya.Stanford.EDU Next aflb.
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Dec 88 11:53:38 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA28325; Wed, 7 Dec 88 11:51:13 PDT
Date: Wed, 7 Dec 88 11:51:13 PDT
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8812071951.AA28325@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: Next aflb.
The next aflb will be, as usual, on Thursday, Dec 8, at 12:30
in room 352. Tom Leighton from MIT will give a SURPRISE talk
(I don't have an abstract myself).
The week after that, on Dec 15, Ilan Vardi from Stanford will give
a talk:
A MEDICAL APPLICATION OF COMBINATORIAL OPTIMIZATION
Ilan Vardi
The process of in vivo genetic recombination (IVGR) is well known to
be succeptible to transfer of adventitious viral or bacterial
information (VBI) during invasive chromosomal dispersion (ICD). In
recent years focus has turned to polymer based occlusive sheaths
(PBOS) as a method of preventing VBI during ICD.
In the talk, the question of minimizing the number of PBOS' given
that all dyadic ICD's with IVGR capability are to be performed in a
group of ICD donors (ICDD) and ICD receptors (ICDR) each with a
different VBI so that no VBI is transmitted. Previous work of Hajnal
and Lovasz found upper and lower bounds that differed by an additive
constant of one. I will fill in this gap by providing an algorithm
that gives the optimal solution for any number of ICDD's and ICDR's.
Caveat lector: anyone who doesn't understand this abstract may be
asked to participate in a real time demonstration of the algorithm.
∂07-Dec-88 1425 X3J13-mailer January agenda items please
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Dec 88 14:25:09 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00440g; Wed, 7 Dec 88 14:22:42 PST
Received: by challenger id AA04360g; Wed, 7 Dec 88 14:18:52 PST
Date: Wed, 7 Dec 88 14:18:52 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8812072218.AA04360@challenger>
To: x3j13@sail.stanford.edu
Subject: January agenda items please
Please let me know if you have something to add to the agenda and how much
time you need.
Please remember the 2 week rule for voting. Things should be mailed by 12/14
to insure receiving 2 weeks before the meeting.
---jan---
∂07-Dec-88 1455 @polya.Stanford.EDU:tah@linz MTC Seminar
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Dec 88 14:55:16 PST
Received: from linz.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA11744; Wed, 7 Dec 88 14:53:28 PDT
Received: by linz.stanford.edu (5.59/25-eef) id AA27848; Wed, 7 Dec 88 14:46:00 PDT
Message-Id: <8812072246.AA27848@linz.stanford.edu>
To: lop@polya
Cc: csd@score
Subject: MTC Seminar
Date: 07 Dec 88 14:44:45 PST (Wed)
From: Tom Henzinger <tah@linz>
John Williams from IBM Almaden will give a talk on FL (the successor of FP).
Friday, Dec. 9, 12 noon, MJH 301.
Abstract:
FL is a functional programming language that encourages the use of
certain data manipulating or "housekeeping" operations in order to
write clear and concise programs. Unfortunately, a straightforward
implementaton of these operations results in very inefficient programs.
We propose to build a compiler that performs code optimization by
transforming programs with housekeeping operations into programs that
use the functional equivalents of looping and procedural constructs.
Our goal is to produce object code that is competitive with the best
Fortran compilers.
∂07-Dec-88 1524 @polya.Stanford.EDU:tah@linz More on finality
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Dec 88 15:24:20 PST
Received: from linz.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA13616; Wed, 7 Dec 88 15:22:16 PDT
Received: by linz.stanford.edu (5.59/25-eef) id AA27883; Wed, 7 Dec 88 15:17:47 PDT
Message-Id: <8812072317.AA27883@linz.stanford.edu>
To: lop@polya
Subject: More on finality
Date: 07 Dec 88 15:17:32 PST (Wed)
From: Tom Henzinger <tah@linz>
I just ran across a paper that proves something very close to John's
conjecture of last Friday (does it?), namely:
Def: An algebra A is fully abstract if for all terms s,t of
nonprimitive (= not observable) sort,
s=t true in A iff
C[s]=C[t] true in A for all contexts C of primitive sort.
Thm: Final models are fully abstract.
A more general form of this result (for partial operations and Horn
specifications) is proved in Broy, Wirsing: Partial Abstract Types,
Acta Informatica 18 (1982). (There are some technical restrictions
that seem, to me, equivalent to Wand's conditions on the existence
of final models.)
Incidentally, Broy and Wirsing give an example in which the difference
between initial and final semantics amounts to quite a few equations.
Consider the following (trimmed-down version of a) Horn theory for
nondeterministic arithmetical expressions:
T0: NAT, +
T1: additional sort: EXP
additional operations: Const: NAT -> EXP
Plus: EXP x EXP -> EXP
Or: EXP x EXP -> EXP
Val: EXP x NAT
additional axioms: Val(Const(n),n)
Val(Plus(x,y),n+m) if Val(x,n) & Val(y,m)
Val(Or(x,y),n) if Val(x,n)
Val(Or(x,y),n) if Val(y,n)
The final model of T1 satisfies, for example, Or(x,x)=x, while the initial
one doesn't. Is it correct to say that the initial model (of EXP) is
freely generated by Const, Plus, and Or, while the final model is isomorphic
to finite nonempty sets (over NAT) with Or being union and Plus such
that, say, Plus({1,2},{1,3})={2,3,4,5} (name?)?
-tom
∂07-Dec-88 1642 misha@polya.Stanford.EDU The title of tomorrow's talk.
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Dec 88 16:42:28 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA18799; Wed, 7 Dec 88 16:38:00 PDT
Date: Wed, 7 Dec 88 16:38:00 PDT
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8812080038.AA18799@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: The title of tomorrow's talk.
The talk tomorrow will be "Packet routing for fixed
connection networks" by Tom Leighton. Sorry, the abstract
seems to have been lost, probably eaten by the notorious virus!
Misha
∂07-Dec-88 1659 X3J13-mailer Issue: DESCRIBE-INTERACTIVE (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Dec 88 16:59:15 PST
Received: from Semillon.ms by ArpaGateway.ms ; 07 DEC 88 15:52:50 PST
Date: 7 Dec 88 15:52 PST
Sender: masinter.pa@Xerox.COM
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
From: CL-cleanup@Sail.Stanford.edu
Subject: Issue: DESCRIBE-INTERACTIVE (Version 4)
reply-to: CL-CLEANUP@Sail.stanford.edu
line-fold: NO
Message-ID: <881207-155250-1594@Xerox>
This issue has two proposals, EXPLICITLY-VAGUE and NO.
Notes from Fairfax meeting...
"...thinks it's stupid to waste time on issues like this....others disagreed."
!
Issue: DESCRIBE-INTERACTIVE
References: DESCRIBE (p441)
Category: CLARIFICATION (EXPLICITLY-VAGUE) / CHANGE (NO)
Edit history: 12-Sep-88, Version 1 by Pitman
23-Sep-88, Version 2 by Masinter
19-Oct-88, Version 3 by Pierson, invert
15-Nov-88, Version 4 by Pierson, two-proposal version
Problem Description:
CLtL is not clear about whether DESCRIBE may be interactive.
While CLtL describes INSPECT as an interactive as an
interactive version of DESCRIBE, it doesn't make explicit
that DESCRIBE is non-interactive. In some implementations it is,
and in other implementations it is not.
Users of systems in which DESCRIBE is not interactive may presume
that it is safe to call DESCRIBE in a batch applications without
hanging the application, which can lead to problems.
Proposal (DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE):
Specify that DESCRIBE is permitted (though not required) to
require user input, and that such input should be negotiated
through *QUERY-IO*.
Descriptive information would continue to go to *STANDARD-OUTPUT*.
Test Case:
The following kind of interaction would be permissible in
implementations which chose to do it:
(DEFVAR *MY-TABLE* (MAKE-HASH-TABLE))
(SETF (GETHASH 'FOO *MY-TABLE*) 1)
(SETF (GETHASH 'BAR *MY-TABLE*) 2)
(SETF (GETHASH 'FOOBAR *MY-TABLE*) 3)
(DESCRIBE *MY-TABLE*)
#<EQ-HASH-TABLE 259> has 3 entries.
Do you want to see its contents? (Yes or No) Yes
Rationale:
This validates current implementations.
Current Practice:
Symbolics Genera asks some questions interactively when describing
some kinds of structured data structures, such as hash tables.
Since users can define their own DESCRIBE methods and took their cue
from the system, describing some user structures also require such
interactions.
Cost to Implementors:
None.
Cost to Users:
User code which depended on DESCRIBE running without user interaction
would have to be modified. Such code is not currently fully portable,
however.
Cost of Non-Adoption:
Users would not know the straight story about whether they should
expect interaction from DESCRIBE.
Benefits:
Implementations which don't do interactive querying in DESCRIBE only
because their not 100% sure it's kosher would be free to do it.
Aesthetics:
Some people might think it's not aesthetic for DESCRIBE to require user
intervention. Not saying whether it's permissible is probably less
aesthetic, though.
Proposal (DESCRIBE-INTERACTIVE:NO):
Specify that DESCRIBE is forbidden to prompt for or require
user input. Permit implementations to extend describe via keyword
arguments to prompt for or require user input as long as the default
action if no keyword arguments are supplied does not prompt for or
require user input.
This is an incompatible change for some implementations.
Test Case:
The following kind of interaction would be permissible in
implementations which chose to do it:
(DEFVAR *MY-TABLE* (MAKE-HASH-TABLE))
(SETF (GETHASH 'FOO *MY-TABLE*) 1)
(SETF (GETHASH 'BAR *MY-TABLE*) 2)
(SETF (GETHASH 'FOOBAR *MY-TABLE*) 3)
(DESCRIBE *MY-TABLE* :INTERACTIVE T)
#<EQ-HASH-TABLE 259> has 3 entries.
Do you want to see its contents? (Yes or No) Yes
Rationale:
DESCRIBE is the only hook a portable program has for providing
information about objects to the user. The potential interactive
functions of DESCRIBE are also likely to be available via INSPECT.
Current Practice:
Symbolics Genera asks some questions interactively when describing
some kinds of structured data structures, such as hash tables.
Since users can define their own DESCRIBE methods and took their cue
from the system, describing some user structures also require such
interactions.
Cost to Implementors:
Symbolics Genera and other non-conforming implementations will have
to change.
Cost to Users:
User code which depends on DESCRIBE running with user interaction
will have to be modified. Such code is not currently portable,
however.
Cost of Non-Adoption:
Users would not have any portable way to have progams inform the
user about object they are dealing with. This might be important in
traces and logs of portable progams or in portable debugging tools.
Benefits:
It will be easier to provide some types of portable functionality.
Aesthetics:
This simplifies the language slightly.
Discussion:
Pitman thinks it's important to clarify this issue, but he isn't fussy
about the particulars.
EXPLICITY-VAGUE proposal is the minimal proposal for compatibility
with current behavior.
Some members of the cleanup committee think that EXPLICITLY-VAGUE is
really a change from the intent of CLtL. However, the current
sentiment is to be less rather than more specific about the behavior
of debugging tools (25.3 of CLtL).
It might be possible to extend DESCRIBE to have additional
keywords (:VERBOSE, :INTERACTIVE-ALLOWED) to cover
additional behavior.
Pierson supports NO because he thinks it's important for there to be
some way for portable programs to present this sort of information
to the user. While the exact data and format presented is
implementation dependent and thus outside of the bounds of
standardization, the existance of such data is neither.
Moon opposes NO because "it creates extra work for implementors and
users of at least one implementation, for no compelling reason."
Moon suggested as a compromise only allowing DESCRIBE to require
user input from "interactive streams". Several other members of the
committee like this in principle but question whether it's feasible
since we have neither defined "interactive streams" nor provided any
portable way to tell if a stream is interactive.
∂07-Dec-88 1803 X3J13-mailer Issue: DOTTED-MACRO-FORMS (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Dec 88 18:03:39 PST
Received: from Semillon.ms by ArpaGateway.ms ; 07 DEC 88 17:12:10 PST
Date: 7 Dec 88 17:11 PST
Sender: masinter.pa@Xerox.COM
to: x3j13@sail.stanford.edu
Subject: Issue: DOTTED-MACRO-FORMS (Version 3)
from: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881207-171210-2206@Xerox>
At the cleanup committee meeting prior in Fairfax, we decided to propose this version.
!
Issue: DOTTED-MACRO-FORMS
References: forms (p54), lists and dotted lists (pp26-27),
DEFMACRO (p145), destructuring macro arguments (p146)
Category: CLARIFICATION/CHANGE
Edit history: 28-Jun-88, Version 1 by Pitman (explicitly-vague vs allow)
01-Oct-88, Version 2 by Masinter (disallow)
15-Nov-88, Version 3 by Pitman (revive allow, flush disallow)
Problem Description:
CLtL is not explicit about whether macro forms may be dotted
lists.
p54 says that only certain forms are "meaningful": self-evaluating
forms, symbols, and "lists".
pp26-27 defines "list" and "dotted list". It goes on to say
``Throughout this manual, unless otherwise specified, it is an
error to pass a dotted list to a function that is specified
to require a list as an argument.''
p146 states that in DEFMACRO destructuring, ``the argument
form that would match the parameter is treated as a
(possibly dotted) list, to be used as an argument forms list
for satisfying the parameters in the embedded lambda list.''
It goes on to say that ". var" is treated like "&rest var"
at any level of the defmacro lambda-list.
Proposal (DOTTED-MACRO-FORMS:ALLOW):
Define that it is permissible for a macro form (or subform)
to be a dotted list when "&REST var" or ". var" is used to match
it. It is the responsibility of the macro to recognize and deal
with such situations.
Rationale:
Some implementations permit dotted lists in macro forms at toplevel.
Most or all implementations permit dotted lists in macro forms at
embedded levels. This proposal makes the language internally
consistent without requiring changes to existing code.
Also, there's no reason to unnecessarily restrict &REST since there
is no computational overhead and since there's no dispute about how
to interpret programmer intent in this gray area.
Test Case:
#1: (DEFMACRO MACW (&WHOLE W &REST R) `(- ,(CDR W)))
(MACW . 1) => ??
#2: (DEFMACRO MACR (&REST R) `(- ,R))
(MACR . 1) => ??
#3: (DEFMACRO MACX (&WHOLE W) `(- ,(CDR W)))
(MACX . 1)
(MACW . 1) => -1 under this proposal.
(MACR . 1) => -1 under this proposal.
(MACX . 1) is an error under CLtL semantics and is not
changed by this proposal. The reason it is an
error is that the argument pattern does not
match. The pattern is dictated by the arguments
-other than- the &WHOLE argument, so the pattern
is () and MACX cannot be called with any arguments.
Current Practice:
A. Some implementations bind W to (MACW . 1) in #1 and #3
and bind R to 1 in #1 and #2.
B. Some implementations bind W to (MACW . 1) in #3
and signal a syntax error in #1 and #2.
C. Some implementations signal a syntax error in #1, #2, and #3.
Symbolics Genera is such an implementation.
Cost to Implementors:
Some implementations would have to eliminate an error check.
Some implementations which try to use APPLY of a normal lambda
to accomplish part of the destructuring (in the non-recursive case)
would have to be slightly more careful.
Cost to Users:
None. This change is upward compatible.
Benefits:
People would know what to expect.
Aesthetics:
Mixed opinion: certainly it is better to specify whether they are
allowed or an error than to be vague.
Some feel that disallowing dotted macro forms helps catch syntax errors.
Some feel that allowing dotted macro forms makes the language more regular.
Discussion:
Goldman@VAXA.ISI.EDU raised this issue on Common-Lisp.
This issue came up primarily in the context of program-written programs;
a macro used in the program generated code might occasionally use
a dotted tail to a list to explicitly represent special conditions.
Allowing dotted macro forms may blur the data/code distinction too much,
particularly for people who are new to Lisp. On the other hand, some people
argue that the point of macros is to help blur that distinction. Macro
forms are data which must be translated to program, and only once the
program claims to be macroexpanded ought syntax restrictions be imposed.
This proposal was rewritten from `DISALLOW' to `ALLOW' after Steele pointed
out in a recent meeting that dotted lists are allowed in subforms and
that permitting them at toplevel would be the most internally consistent
interpretation.
Pitman supports DOTTED-MACRO-FORMS:ALLOW.
∂07-Dec-88 2058 X3J13-mailer Issue: EXPT-RATIO (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Dec 88 20:58:48 PST
Received: from Semillon.ms by ArpaGateway.ms ; 07 DEC 88 20:51:44 PST
Date: 7 Dec 88 20:51 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: EXPT-RATIO (Version 2)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
from: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881207-205144-2665@Xerox>
!
Forum: Cleanup
Issue: EXPT-RATIO
References: CLtL pages 204 and 211
Category: CLARIFICATION
Edit history: Version 1, 4-Oct-88, by Aspinall and Moon
Version 2, 6-Oct-88, Masinter (very minor discussion)
Version 3, 31-Oct-88, Masinter (fix typo)
Problem description:
The comment (page 204, 2nd para) that "... an implementation [of expt]
might choose to compute (expt x 3/2) as if it had been written
(sqrt (expt x 3))" disagrees with the principal value definition on
page 211. See the example below for a case where the two disagree. We
believe the principal value definitions are consistent and reasonable,
therefore the implementation comment is wrong.
Proposal (EXPT-RATIO:P.211):
Clarify that (sqrt (expt x 3)) is not equivalent to (expt x 3/2)
and that page 211 rules.
Examples:
(defvar x (exp (/ (* 2 pi #c(0 1)) 3))) ;exp(2.pi.i/3)
(expt x 3) => 1 (except for round-off error)
(sqrt (expt x 3)) => 1 (except for round-off error)
(expt x 3/2) => -1 (except for round-off error)
There can be no question that
(expt x 3) ==> 1
because expt is single-valued with an integer second argument, and
(sqrt 1) ==> 1
definitely follows the principal branch of the square root function.
But (expt x 3/2) is defined as (exp (* (log x) 3/2)) (page 211).
(log x) ==> 2.pi.i/3
according to the definition of the logarithm's branch cuts on page 211
(which really comes down to the branch cuts of phase - page 210), so
(* (log x) 3/2) ==> pi.i
and
exp(pi.i) is -1.
Rationale:
We believe the principal value definitions are consistent and
reasonable, therefore the implementation comment is wrong.
Current practice:
Symbolics Genera 7.3 currently returns the wrong answer, following page
204 rather than page 211. Lucid Common Lisp, and
Envos Medley implement the proposal.
Cost to Implementors:
The obvious code changes in complex expt.
Cost to Users:
None.
Cost of non-adoption:
Self-contradictory language specification.
Benefits:
Users can better predict the branch cuts in expt.
Discussion:
Mathematical Explanation: When the expt function returns a complex result
in CL (Cartesian) form, the phase of the complex number is effectively
canonicalized. Information is lost, and that information is necessary to
specify upon which branch of the sqrt function the final result should lie.
Another way to put it would be that although
sqrt(expt(x,3)) = expt(x,3/2)
where expt and sqrt are the mathematical multi-valued functions, it is not
true that:
pvsqrt(pvexpt(x,3)) = pvexpt(x,3/2)
where pvexpt and pvsqrt denote the principal value versions of those functions.
∂07-Dec-88 2143 X3J13-mailer Issue: FORMAT-PRETTY-PRINT (Version 7)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Dec 88 21:43:15 PST
Received: from Semillon.ms by ArpaGateway.ms ; 07 DEC 88 21:33:31 PST
Date: 7 Dec 88 21:33 PST
Sender: masinter.pa@Xerox.COM
to: X3J13@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
Subject: Issue: FORMAT-PRETTY-PRINT (Version 7)
cc: Masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881207-213331-2723@Xerox>
!
Issue: FORMAT-PRETTY-PRINT
References: FORMAT (pp. 385-388), PRIN1 (p. 83), PRINC (p. 83),
WRITE (p. 382), *PRINT-PRETTY* (p. 371)
Category: CLARIFICATION
Edit history: Version 1 by Pierson 3/4/88
Version 2 by Pierson 5/24/88 (fix name typo)
Version 3 by Pierson 6/10/88 incorporate comments
Version 4 by Pierson 6/10/88 comments from Van Roggen
Version 5 by Masinter 2-Oct-88
Version 6 by Pierson 11/10/88 final nits
Version 7 by Pierson 11/15/88 "does" => "does not"
Problem description:
The FORMAT operators, ~A and ~S are defined to print their argument as
PRINC and PRIN1 respectively. The text does not say whether or not
these FORMAT operators must obey the *PRINT-PRETTY* flag.
Proposal (FORMAT-PRETTY-PRINT:YES):
Specify that FORMAT does not rebind any of the printer control
variables (*PRINT-...) except as follows:
~A
Binds *PRINT-ESCAPE* to NIL.
~S
Binds *PRINT-ESCAPE* to T.
~D
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 10.
~B
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 2.
~O
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 8.
~X
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 16.
~R
Iff a first argument is specified, binds *PRINT-ESCAPE* to NIL,
*PRINT-RADIX* to NIL, and *PRINT-BASE* to the value of the first
argument.
Iff no aruments are specified, binds *PRINT-BASE* to 10.
~@C
Binds *PRINT-ESCAPE* to T.
~F,~G,~E,~$
Binds *PRINT-ESCAPE* to NIL.
Test Cases/Examples:
(LET ((TEST '#'(LAMBDA (X)
(LET ((*PRINT-PRETTY* T))
(PRINT X)
(FORMAT T "~%~S " X)
(TERPRI) (PRINC X) (PRINC " ")
(FORMAT T "~%~A " X)))))
(FUNCALL (EVAL TEST) TEST))
This should print four copies of the above lambda expression. The
first pair should appear identical and the second pair should appear
identical. The only difference between the two pairs should be the
absence of string quotes in the second pair.
Rationale:
FORMAT should interact with the printer control variables in a
predictable way. This proposal is one of the two simplest possible
definitions and provides the most flexibility to the user.
A major advantage of this proposal is that the following two
expressions are guaranteed to have exactly the same effect:
(FORMAT stream "~S" object)
(PRIN1 object stream)
Thus use or non-use of FORMAT becomes a purely stylistic matter.
Current practice:
Ibuki Lisp and the TI Explorer obey the binding of *PRINT-PRETTY*.
Lucid Common Lisp always applies ~A and ~S with *PRINT-PRETTY* bound
to NIL.
Cost to Implementors:
While changing FORMAT to not bind *PRINT-foo* variables is trivial,
there are some painful implications. How does a pretty-printing ~A
interact with MINCOL, etc? How much of the user interface depends on
FORMAT in ways that might be uglified by pretty printing?
Cost to Users:
Truely portable code shouldn't be affected because existing
implementations are inconsistent. Despite this, there are probably a
number of user programs in non-complying implementations which will
have to change whichever way this is decided.
Cost of non-Adoption:
The interaction of FORMAT and the printer control variables (especially
*PRINT-PRETTY*) will remain undefined. This will continue to make
portable Common Lisp programming harder than it need be.
Benefits:
Life will be easier for users in two ways: (1) one more portability
problem will be removed, and (2) users will be more likely to be able
to persuade environmental features like debuggers to print in their
preferred way.
Aesthetics:
The interaction between two related parts of output will be clarified
in a simple way.
Discussion:
It is important to specify exactly what of Common Lisp's special
variables get rebound by other functions and macros in Common Lisp.
This cleanup issue addresses the interaction of FORMAT and the
*PRINT- variables. There may be other similar interactions in
Common Lisp that need clarification.
Otherwise, code that depends on FORMATs action in one implementation
will not port to others that do not have the same behavior.
CLtL might change as follows:
Add a header "Printer Control Variables" before the description of
*PRINT-ESCAPE* on page 370.
Add the following paragraph to page 386 just before the paragraph
starting with "It is an error":
"The FORMAT function by itself never binds any of the printer
control variables. Specific FORMAT directives bind exactly the
printer control variables specified in their description. While
implementations may specify the binding of new, implementation
specific printer control variables for each FORMAT directive, they
may neither bind any standard printer control variables not
specified in description of a FORMAT directive nor fail to bind
any standard printer control variables as specified in the
description."
There was some discussion on whether *PRINT-BASE* should be bound for
~F, ~G, ~E, and ~$. This is not necessary because page 341 of CLtL
states that floating point numbers are always printed in base 10.
∂08-Dec-88 0613 X3J13-mailer Re: January agenda items please
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 8 Dec 88 06:13:03 PST
Date: 8 Dec 1988 09:10-EST
Sender: ROSENKING@A.ISI.EDU
Subject: Re: January agenda items please
From: ROSENKING@A.ISI.EDU
To: jlz@LUCID.COM
Cc: mathis@A.ISI.EDU
Cc: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU] 8-Dec-88 09:10:30.ROSENKING>
In-Reply-To: <8812072218.AA04360@challenger>
What is the official status of the ISO meeting, is it on or off ?
It appears, from monitoring the mail since the last ISO meeting,
that there are several issues which need to be worked out. Do our
ISO reps and chairman believe that we should abandon the meeting
or perhaps try to take the initiative to bring the ISO reps all
together to try to solve some of the problems. Members such as
myself who are outside of this loop can not appreciate the true
status of the situation.
∂08-Dec-88 0913 @Score.Stanford.EDU:DEK@SAIL.Stanford.EDU special seminar today
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Dec 88 09:13:12 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 8 Dec 88 09:10:50-PST
Message-ID: <vN83h@SAIL.Stanford.EDU>
Date: 08 Dec 88 0910 PST
From: Don Knuth <DEK@SAIL.Stanford.EDU>
Subject: special seminar today
To: faculty@SCORE.STANFORD.EDU
Tom Leighton from MIT is our special guest speaker at the Algorithms
For Lunch Bunch at 12:30 in room 352. He will talk about
Packet Routing on Fixed Connection Networks.
∂08-Dec-88 1056 X3J13-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 10:56:00 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 10:39:12 PST
Date: 8 Dec 88 10:38 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 5)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-103912-3821@Xerox>
!
Forum: Cleanup
Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
References: CLtL p. 27, 47-48, 61
"Artifical Intelligence Programming", Charniak et. al.
X3J13/86-003 (A:>GLS>clarifications.text.4)
Category: CLARIFICATION, ADDITION
Edit history: Version 1, 23-Nov-1987 Sandra Loosemore
Version 2, 15-Jan-1988 Sandra Loosemore
(incorporate comments from Scott Fahlman & others)
Version 3, 13-Feb-88 Masinter
Version 4, 2-Oct-88 Masinter (update references,
discussion)
Version 5, 14-Nov-88 Masinter (add to discussion)
Related issues: FUNCTION-TYPE-KEY-NAME,
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
REST-LIST-ALLOCATION
Problem description:
The FUNCTION type specifier list is provided to allow declaration of
function argument types and return value types. This type specifier uses a
syntax similar to the usual lambda list syntax to specify which types go
with which lambda list variables. However, this is actually of limited
usefulness in the context of a declaration, where one normally wants type
information about the actual arguments which can be passed to the function
rather than the lambda variables to which they are bound.
There is a particular problem with &REST lambda variables, which are always
bound to a value of type LIST. For the sake of consistency, it would seem
that the corresponding type given in the FUNCTION declaration must also be
LIST, but since this provides no information about the actual arguments,
some users/implementors have instead adopted the convention of supplying
the type of the actual arguments which are gathered into the list.
CLtL is vague on the issue, mentioning only that &REST may appear in the
type specifier without touching upon its interpretation.
Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE):
Clarify that, in the FUNCTION type specifier, the type specifier provided
with &REST is the type of each actual argument, not the type of the
corresponding lambda variable.
Example:
The type of the function + would be specified as:
(FUNCTION (&REST NUMBER) NUMBER)
Rationale:
This is more useful than specifying that the type of a &REST parameter must
be LIST, since it provides information about the actual arguments.
Current practice:
There does not appear to be any concensus on this issue. Most Common Lisp
implementations currently ignore FUNCTION type declarations. The only
examples found so far are in a text book on Common Lisp, which follows the
proposed syntax.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier may continue to do
so. Probably only a small amount of code would have to be written/changed
in implementations that currently think that the &REST argument should be
LIST.
Cost to Users:
Users who have been using the convention that the &REST type parameter must
be LIST will have to change their code. However, because this issue is so
unclear, the FUNCTION type specifier is probably not used very much.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of
limited use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language
design.
Esthetics:
Debatable. One the one hand, since the argument type syntax used by the
FUNCTION type specifier mirrors normal lambda-list syntax, it would be
cleaner and less confusing to provide the type of the lambda variable
rather than the type of the actual arguments. However, considering the
types specified in the FUNCTION specifier to be the types of the actual
arguments rather than the types of the parameters as seen on the receiving
end makes the proposed semantics more palatable.
Discussion:
This issue provoked considerable debate in the cleanup committee and at
X3J13.
Many people objected to this proposal, and would prefer the alternative
that the type given after a &REST in a function declaration apply to the
value of the formal parameter rather than the actual arguments. This would
be even more useful if complex LIST type specifiers were part of Common
Lisp (as the proposal in issue LIST-TYPE-SPECIFIER might add) or if it were
possible to declare, for example, &REST {keyword integer}*.
Some additional arguments against this proposal are the apparent mismatch
between the external declarations of type and the internal ones. It might
be that this proposals presumes that rest lists are always lists, and the
following is illegal:
(DEFUN FOO (&REST X) X)
(APPLY #'FOO T)
which is not otherwise explicitly forbidden, but for which there is no
legitimate declaration.
∂08-Dec-88 1129 X3J13-mailer Issue: GET-MACRO-CHARACTER-READTABLE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 11:29:34 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 11:10:31 PST
Date: 8 Dec 88 11:10 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: GET-MACRO-CHARACTER-READTABLE (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-111031-3954@Xerox>
!
Issue: GET-MACRO-CHARACTER-READTABLE
References: CLtL p.361: COPY-READTABLE, SET-SYNTAX-FROM-CHAR, and
GET-MACRO-CHARACTER
CLtL p.364: GET-DISPATCH-MACRO-CHARACTER,
CLtL p.378: Example in middle of page
Category: CLARIFICATION/CHANGE
Edit history: Version 1, 16-Nov-88, by JonL
Version 2, 8-Dec-88, by Masinter (fix typo)
Problem description:
The 'readtable' argument to GET-DISPATCH-MACRO-CHARACTER and to
GET-MACRO-CHARACTER must be of type READTABLE, without mention of
what happens when NIL is supplied. This may have been simply
an oversight, since it makes more sense for it to refer to values from
the standard readtable. Both COPY-READTABLE and SET-SYNTAX-FROM-CHAR
explicitly say that a NIL in the 'from-readtable' argument refers to the
standard readtable. Also, an example in the middle of the page, CLtL
p.378, supplies a NIL to GET-MACRO-CHARACTER, and is clearly intending
to access the standard readtable values.
Proposal (GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD)
Specify that a NIL readtable argument to GET-DISPATCH-MACRO-CHARACTER
and to GET-MACRO-CHARACTER mean the same thing it does for COPY-READTABLE,
and SET-SYNTAX-FROM-CHAR; namely a reference to the standard readtable.
Thus (GET-MACRO-CHARACTER <char> NIL) would be equivalent to
(GET-MACRO-CHARACTER <char> (COPY-READTABLE)), but without consing.
Test Cases:
(let ((standard-rt (copy-readtable))
(chars '(#\* #\= #\| #\A #\ #\( #\# #\1)))
;; Test Case 1
(dolist (char chars)
(assert (eq (get-macro-character char nil)
(get-macro-character char standard-rt))
() "Lose on character ~C" char))
;; Test Case 2
(dolist (char chars)
(assert (eq (get-dispatch-macro-character #\# char nil)
(get-dispatch-macro-character #\# char standard-rt))
() "Lose on #\# dispatch character ~C" char))
;; Test Case 3
(assert (eq (get-dispatch-macro-character #\# #\A nil)
(get-dispatch-macro-character #\# #\a nil))
() "Lose on #\# dispatch character ~C" char)
)
Rationale:
Probably was the original intent; somebody wants it; also see "Esthetics".
Current practice:
Symbolics and Xerox have already implemented the proposal; Lucid, VAXLISP,
and KCL stuck to the more rigid interpretation.
Cost to Implementors:
Trivial.
Cost to Users:
None.
Cost of non-adoption:
Minor worry about porting between implementations that support the
generalization and those that don't; minor worry about consing when
calling (COPY-READTABLE) to get at standard readtable semantics.
Performance impact:
See "Cost of non-adoption".
Benefits:
See "Cost of non-adoption".
Esthetics:
Increases parallel design among similar readtable functions.
Discussion:
This question was raised in the Common Lisp mailing last summer:
Date: 19 Jul 88 13:35
Subject: Question about readtable null arguments
From: quiroz%cs.rochester:EDU:Xerox
To: common-lisp%sail.stanford:EDU:Xerox
∂08-Dec-88 1147 X3J13-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS (Version 7)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 11:45:17 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 88 11:32:56 PST
Date: 8 Dec 88 11:30 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (Version 7)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-113256-4026@Xerox>
!
Forum: Cleanup
Issue: HASH-TABLE-PACKAGE-GENERATORS
References: Issue: DO-SYMBOLS-DUPLICATES
Category: ADDITION
Edit history: Version 1, 23-May-88 JonL
Version 2, 6-Oct-88 JonL (convert to "with" scoping).
Version 3, 7-Oct-88 JonL (mly's syntax for package iterator)
Version 4, 8-Nov-88 JonL (fix example; clarify some nits)
Version 5, 22-Nov-88 Moon (improve syntax for package iterator,
add examples, fix typos)
Version 6, 6-Oct-88 JonL (final nits)
Version 7, 8-Dec-88, Masinter (add comment to discussion)
Problem description:
The Iteration subcommittee would like the several iteration proposals to be
writable in portable Common Lisp code. Unfortunately, the only complete
access to hash-tables and packages is through MAPHASH and DO-SYMBOLS (and
DO-EXTERNAL-SYMBOLS and DO-ALL-SYMBOLS); none of these existing primitives
is satisfactory for building complex iteration clauses. In particular,
these primitives are fully packaged and do not allow control over the
individual operations of starting the iteration, stopping the iteration,
and advancing to the next step of the iteration.
Proposal (HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER)
Add two new macros WITH-HASH-TABLE-ITERATOR and WITH-PACKAGE-ITERATOR
to the language as follows:
WITH-HASH-TABLE-ITERATOR ((<next-fn> <hash-table>) &body body) [Macro]
Within the lexical scope of 'body', the name <next-fn> is defined
via MACROLET such that successive invocations of (<next-fn>) will
return the items, one by one, from the hash-table which is obtained
by evaluating <hash-table> only once.
An invocation (<next-fn>) returns three values as follows:
1. a boolean indicating whether an entry is returned (T says yes)
2. the key item (of a <key, value> pair)
3. the value item (of a <key, value> pair)
After all entries have been returned [by successive invocations of
(<next-fn>)], then only one value is returned, namely NIL.
WITH-PACKAGE-ITERATOR ((<next-fn> <package-list> [Macro]
&rest <symbol-types>)
&body body)
Within the lexical scope of 'body', the name <next-fn> is defined
via MACROLET such that successive invocations of (<next-fn>) will
return symbols, one by one, from the packages that are elements
of the list which is obtained by evaluating <package-list> only once.
Each element of <package-list> can be a package or the name of a
package.
The order of symbols returned does not necessarily reflect the order
of packages in <package-list>. When <package-list> has more than
one element, it is unspecified whether duplicate symbols are
returned once or more than once. Even when <package-list> has only
one element, it is unspecified whether symbols inherited from
multiple packages are returned more than once. See the proposal
DO-SYMBOLS-DUPLICATES:ALLOWED.
As a convenience, the value of <package-list> can be a package or
the name of a package; this is equivalent to a list of one element.
An argument of NIL is treated as an empty list of packages.
The <symbol-types> subform consists of one or more symbols from the
set {:INTERNAL, :EXTERNAL, :INHERITED}. Their order does not
matter. The <symbol-types> subform is not evaluated. This controls
which symbols accessible in a package are returned:
:INTERNAL means the symbols that are present in the package,
but which are not exported;
:EXTERNAL means the symbols that are present and exported;
:INHERITED means the symbols that are exported by used packages
and that are not shadowed.
When more than one argument is supplied for <symbol-types>, then a
symbol is returned if its accessibility matches any one of the
<symbol-types> specified. WITH-PACKAGE-ITERATOR signals an error if
no <symbol-types> are specified or if a <symbol-type> not recognized
by the implementation is specified. Implementations are permitted to
extend this syntax by recognizing additional symbol accessibility types.
An invocation (<next-fn>) returns four values as follows:
1. a boolean indicating whether a symbol is returned (T says yes)
2. a symbol (accessible in one the indicated packages)
3. the accessibility type for that symbol; i.e. one of
:INTERNAL, :EXTERNAL, or :INHERITED
4. the package from which the symbol has been accessed.
After all symbols have been returned [by successive invocations of
(<next-fn>)], then only one value is returned, namely NIL.
The fourth return value is one of the packages present or named in the
<package-list> argument. The meaning of the second, third, and fourth
values is that the returned symbol is accessible in the returned package
in the way indicated by the second return value:
:INTERNAL ==> present, and not exported,
:EXTERNAL ==> present, and exported,
:INHERITED ==> not present (thus not shadowed) but inherited
from some used package.
It is unspecified what happens if any of the implicit interior state
of an iteration is returned outside the dynamic extent of the WITH-...
form (such as by returning some closure over the invocation form).
Any number of invocations of with-hash-table-iterator and
with-package-iterator can be nested, and the body of the innermost one
can invoke all of the MACROLET'ed macros, provided all those macros
have distinct names.
Examples:
The following function should return T on any hash-table, and signal
an error if the usage of 'with-hash-table-iterator' doesn't agree
with the corresponding usage of 'maphash'.
(defun test-hash-table-iterator (hash-table)
(let ((all-entries '())
(generated-entries '())
(unique (list nil)))
(maphash #'(lambda (key value) (push (list key value) all-entries))
hash-table)
(with-hash-table-iterator (generator-fn hash-table)
(loop
;;Note -- this is the "trivial" LOOP of CLtL p121
(multiple-value-bind (more? key value) (generator-fn)
(unless more? (return))
(unless (eql value (gethash key hash-table unique))
(error "Key ~S not found for value ~S" key value))
(push (list key value) generated-entries))))
(unless (= (length all-entries)
(length generated-entries)
(length (union all-entries generated-entries :test #'equal)))
(error "Generated entries and Maphash entries don't correspond"))
t))
The following function should return T on any package, and signal
an error if the usage of 'with-package-iterator' doesn't agree
with the corresponding usage of 'do-symbols'.
(defun test-package-iterator (package)
(unless (packagep package)
(setq package (find-package package)))
(let ((all-entries '())
(generated-entries '()))
(do-symbols (x package)
(multiple-value-bind (symbol accessibility)
(find-symbol (symbol-name x) package)
(push (list symbol accessibility) all-entries)))
(with-package-iterator (generator-fn package
:internal :external :inherited)
(loop
;;Note -- this is the "trivial" LOOP of CLtL p121
(multiple-value-bind (more? symbol pkg accessibility)
(generator-fn)
(unless more? (return))
(let ((l (multiple-value-list (find-symbol (symbol-name symbol)
package))))
(unless (equal l (list symbol accessibility))
(error "Symbol ~S not found as ~S in package ~A [~S]"
symbol accessibility (package-name package) l))
(push l generated-entries)))))
(unless (and (subsetp all-entries generated-entries :test #'equal)
(subsetp generated-entries all-entries :test #'equal))
(error "Generated entries and Do-Symbols entries don't correspond"))
t))
The following function prints out every interned symbol (possibly
more than once):
(defun print-all-symbols ()
(with-package-iterator (next-symbol (list-all-packages)
:internal :external)
(loop
;;Note -- this is the "trivial" LOOP of CLtL p121
(multiple-value-bind (more? symbol) (next-symbol)
(if more?
(print symbol)
(return))))))
The following could be an acceptable definition of the function
MAPHASH, implemented by WITH-HASH-TABLE-ITERATOR"
(defun maphash (function hash-table)
(with-hash-table-iterator (next-entry hash-table)
(loop (multiple-value-bind (more key value) (next-entry)
(unless more (return nil))
(funcall function key value)))))
Rationale:
The particular way in which hash-tables and packages are represented
need not be standardized, or even exposed to the user. Yet a simpler
handle on them is needed for the various iteration paradigms to be written
in portable code. In fact, after these iterator macros are put into an
implementation, then MAPHASH and DO-<mumble>-SYMBOLS are trivial usages
of them; but no _efficient_ use of the current primitives will provide
the effect of the new macros, namely a form that _returns_ the elements
of a table "one by one".
Current Practice:
Nobody does it this way, but both Symbolics and Lucid are not far off.
Cost to Implementors:
Moderate. Possibly a couple day's to a week's work for an implementation
that has to start completely afresh. Something like this is already being
done by the standard package macros [CLtL, p187].
Cost to Users:
None.
Benefits:
Will provide a more basic primitive for iterating over hash-tables and
packages; will permit new iteration paradigms to be written in portable code.
Aesthetics:
All other things being equal, it is better to have more general primitives
than less general ones.
Discussion:
The Iteration Subcommittee supports this proposal (or, "used to" --
JonL 6-Oct-88).
One must be careful not to assume that the invocation (<next-fn>) is a
"generator" function call -- since <next-fn> is MACROLET'd in an
implementation dependent way, it could even turn into a special form like
(if something
(values nil)
(yet-another-function-call))
The scoping called for herein may not be quite so useful to the "generators"
style proposals; in particular they offer an interface wherein one may
create a "generator" function of indefinite extent that returns, one-by-one,
the elements of the table. The constrained scoping implicit in these
WITH-... macros is not so much for any kind of optimization, but rather
for coordination of such hash-table "locking" as may occur in multi-
processing implementations like Symbolics. Nevertheless, Dick Waters
thinks these macros should be put in anyway, since it clearly is a
requirement for a portable LOOP, and can be use in a limited context
(i.e., not "indefinite scope") for portable versions of ITERATE and OSS.
Of course, if an implementation _can_ support an indefinite extent for
a "generator" object returned out of the iterator forms, it is allowed
to do so by this proposal.
The following macro definitions show how Common Lisp's DO-mumble-SYMBOLS
macros could have been defined in terms of WITH-PACKAGE-ITERATOR. They
are intended as illustrative examples, not as new specifications of those
built-in Common Lisp facilities. [PARSE-BODY is as defined in Guy Steele's
"Clarifications" of 6-Dec-85.]
(defmacro do-symbols ((var &optional (package `*package*) result-form)
&body body
&environment env)
(multiple-value-bind (body decls docstring) (parse-body body env)
`(with-package-iterator (next-symbol (list ,package)
:internal :external :inherited)
(let (more? ,var)
,@decls
(loop
(unless (multiple-value-setq (more? ,var) (next-symbol))
(setq ,var nil)
(return ,result-form))
,@body)))))
(defmacro do-external-symbols ((var &optional (package `*package*) result-form)
&body body
&environment env)
(multiple-value-bind (body decls docstring) (parse-body body env)
`(with-package-iterator (next-symbol (list ,package)
:external)
(let (more? ,var)
,@decls
(loop
(unless (multiple-value-setq (more? ,var) (next-symbol))
(setq ,var nil)
(return ,result-form))
,@body)))))
(defmacro do-all-symbols ((var &optional result-form)
&body body
&environment env)
(multiple-value-bind (body decls docstring) (parse-body body env)
`(with-package-iterator (next-symbol (list-all-packages)
:internal :external)
(let (more? ,var)
,@decls
(loop
(unless (multiple-value-setq (more? ,var) (next-symbol))
(setq ,var nil)
(return ,result-form))
,@body)))))
-------
"Why not define <next-fn> as a local function as if defined by
FLET rather than a macro as if defined by MACROLET? "
"A macro gave more scope to the implememtation to optimize
without losing anything essential in these circumstances."
∂08-Dec-88 1248 nii@sumex-aim.stanford.edu [Richard P. Gabriel <rpg@lucid.com> : US/Japan Workshop on Parallel
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 8 Dec 88 12:47:34 PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA17505; Thu, 8 Dec 88 12:46:45 PST
Date: Thu, 8 Dec 1988 12:46:44 PST
From: Penny Nii <nii@sumex-aim.stanford.edu>
To: aap@sumex-aim.stanford.edu
Subject: [Richard P. Gabriel <rpg@lucid.com> : US/Japan Workshop on Parallel
Lisp ]
Message-Id: <CMM.0.88.597617204.nii@sumex-aim.stanford.edu>
Anyone interested in this? What about the Lamina folks...penny
---------------
Return-Path: <rpg@lucid.com>
Received: from lucid.com by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA00470; Tue, 29 Nov 88 15:52:06 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA02214g; Tue, 29 Nov 88 15:49:16 PST
Received: by challenger id AA00766g; Tue, 29 Nov 88 15:44:15 PST
Date: Tue, 29 Nov 88 15:44:15 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8811292344.AA00766@challenger>
To: jmc@sail.stanford.edu, clt@sail.stanford.edu, jsw@sail.stanford.edu,
nii@SUMEX-AIM.Stanford.EDU, arg@lucid.com, rhh@ai.ai.mit.edu,
ran@VX.lcs.mit.edu, gifford@xx.lcs.mit.edu, tk@ai.ai.mit.edu,
gls@think.com, Kessler@cs.utah.edu, pierson@MULTIMAX.ENCORE.COM,
allen@bbn.com, zippel@stony-brook.scrc.symbolics.com
Subject: US/Japan Workshop on Parallel Lisp
Colleagues
This is the first and only announcement for the Joint US/Japan
Workshop on Parallel Lisp, to be held in Sendai, Japan. We expect to
hold a second Parallel Lisp workshop in the US within a year of the
first workshop. Here are the important facts:
Date: June 5, 6, 7, and 8
Place: Aoba Memorial Building
School of Engineering
Tohuko University
Sendai, Japan
Organizers: <US> Dr. Richard P. Gabriel (Stanford University and Lucid, Inc.)
<Japan> Professor Takayasu Ito (Tohoku University)
Major Topics:
Parallelism and Concurrency in Lisp
Parallel Lisp Languages
Parallel Machines for Lisp and Parallel Lisp
Object-oriented Systems for Parallel Lisp
Applications
Right now there are 16 senior researchers from Japan who are coming,
and I would like the US to have a good showing.
At this time I would like to get a list of those people who will
definitely be able to attend. There is limited funding available for
the workshop. Namely, Professor Ito is able to pay for train travel
between Tokyo and Sendai, and possibly housing and meals, for
University folks.
Please send me a note stating whether you will be able to come and a
short abstract of what you would like to say. There will be both long
and short talks by selected individuals.
Please send mail to: rpg@sail.stanford.edu
-rpg-
∂08-Dec-88 1334 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Extra FOCS Proceedings.
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Dec 88 13:34:21 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA00925; Thu, 8 Dec 88 13:33:48 PDT
Message-Id: <8812082133.AA00925@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 8 Dec 88 13:34:24 PST
Received: by BYUADMIN (Mailer R2.01) id 4446; Thu, 08 Dec 88 14:32:23 MST
Date: Thu, 8 Dec 88 15:05:06 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Alok Aggarwal <AGGARWA%YKTVMX.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Alok Aggarwal <AGGARWA%YKTVMX.BITNET@forsythe.stanford.edu>
Subject: Extra FOCS Proceedings.
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Some of you may be wondering as to what happened to the extra
proceedings that you paid for at FOCS 1988. It turns out that IEEE
Computer Society was quite backlogged when we sent them the list for the
extra proceedings and they did not start mailing these out until Dec.
1, 1988. So, please be patient for another week or two and I am sure
you will receive them (if you paid for them, that is).
Sorry for the delay and all the best,
Alok Aggarwal.
∂08-Dec-88 1524 X3J13-mailer Issue: HASH-TABLE-TESTS (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 15:24:30 PST
Received: from Salvador.ms by ArpaGateway.ms ; 08 DEC 88 15:11:34 PST
Date: 8 Dec 88 15:06 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: HASH-TABLE-TESTS (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-151134-4673@Xerox>
!
Issue: HASH-TABLE-TESTS
References: CLtL, p382 (third paragraph), and p383
Issue EQUAL-STRUCTURE
Requires Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
Category: Addition
Edit history: 26-Sep-88 Version 1 by JonL
8-Dec-88 Version 2 by Masinter
(as per cl-cleanup)
Problem Description:
A great many users try to coalesce two equivalent DEFSTRUCT instances,
or two equivalent pointer arrays, using hash tables; but they are rudely
awakened when they find out that EQUAL is not an appropriate test for
this case, and that there is no :test argument to MAKE-HASH-TABLE which
will "hash on non-tree structures".
Proposal: HASH-TABLE-TESTS:ADD-EQUALP
With the advent of the issue CONTAGION-ON-NUMERICAL-COMPARISONS, we
can expect EQUALP to be a true equivalence function, and thus a suitable
candidate for the :test function to MAKE-HASH-TABLE. Hash-tables will
come in four kinds, the difference being whether the keys are compared
with EQ, EQL, EQUAL, or EQUALP.
Examples:
> (defstruct foo a b c)
FOO
> (setq x (make-foo :a 1 :b 'b :c '(1 . 2))
x-copy (make-foo :a 1 :b 'b :c '(1 . 2)))
#S(FOO A 1 B B C (1 . 2))
> (setq y #(1 B (1 . 2))
y-copy (copy-seq y))
#(1 B (1 . 2))
> (setq ht-equal (make-hash-table :test 'equal)
ht-equalp (make-hash-table :test 'equalp))
#<Hash-Table BB1F7B>
> (progn (setf (gethash x ht-equal) t) (setf (gethash x ht-equalp) t)
(setf (gethash y ht-equal) t) (setf (gethash y ht-equalp) t))
T
> (gethash x-copy ht-equal)
NIL
NIL
> (gethash x-copy ht-equalp)
T
T
> (gethash y-copy ht-equal)
NIL
NIL
> (gethash (copy-seq y) ht-equalp)
T
T
>
Rationale:
Implementing hash-tables efficiently is not an easy task; it makes more
sense for this to be standardly available than for individual programmers
to keep trying to re-invent this obscure part of technology.
Current Practice:
Lucid's release 3.0 implements this proposal [some 2.1-level release
supported it "provisionally"]. Symbolics implementation is reputed
to be robust enough to implement this proposal trivially.
Cost to Implementors:
Moderate. Implementors have already dealt with EQUAL; the only tricky
part will be ensuring the implication:
"If 'a' is EQUALP to 'b', then 'a' and 'b' must lie in the
same collision chain in any given EQUALP hash table"
It has been suggested that merely linear searching a table is an acceptable
implementation technique for CL's hash-tables [although no serious
implementation limits itself thus] and that such tables have no "collision
chains"; but in fact, this is the degenerate case wherein all entries are
in the same collision chain, so the implication is trivially satisfied.
Some persons prefer to say that the "reprobe sequence will be the same for
the two items", rather than using the term "collision chain"; the meaning
is the same.
Cost to Users:
None. This is an entirely upwards-compatible addition.
Cost of non-adoption:
Continuing bug reports from users about why "hashing
doesn't work" when said user tries entering pointer-containing objects
other than cons cells into hash tables. Continuing delay in same
user's work until they figure out a new strategy for identifying
equivalent structures. More difficulty in debugging their alternatives.
Benefits:
Addresses one aspect of the difficult equivalence problem. Makes
hash tables more useful. Permits case-insensitive hashing
on strings [tables of type EQUAL are case-sensitive on strings];
another use is to allow = comparison for numbers
[tables of type EQUAL use EQL on numbers].
Aesthetics:
Reduces the discontinuity between basic equivalence functions and those
usable as equivalence relations in hash-tables.
Discussion:
With the rejection of all the issues related to EQUAL-STRUCTURE, there is
little or no hope that EQUAL will be "beefed up" to meet the expectations
of so many of the user community on compound structures. If one wants
a hash-table with a :test function that has fewer equivalence classes
(i.e., does more "coalescing"), then there is no alternative now except
to use the function EQUALP.
It would also be possible to extend hash tables to allow = or
STRING=, but those are not being proposed at this time.
∂08-Dec-88 1644 X3J13-mailer Issue: LCM-NO-ARGUMENTS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 16:43:50 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 16:29:52 PST
Date: 8 Dec 88 15:45 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: LCM-NO-ARGUMENTS (Version 1)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-162952-4859@Xerox>
!
Forum: Cleanup
Issue: LCM-NO-ARGUMENTS
References: CLtL p. 202
Category: ADDITION
Edit history: Version 1, Guy Steele 10/17/88
Problem description:
CLtL incorrectly states that (lcm) should return infinity, and
therefore specifies that giving lcm no arguments is an error.
In point of mathematical fact, 1 is the identity for the lcm operation.
Proposal (LCM-NO-ARGUMENTS:1):
Define (lcm) to return the integer 1.
Examples:
(lcm) => 1
Currently the behavior in this case is implementation-dependent.
Rationale:
Doing what is mathematically right.
Current practice:
KCL signals an error.
Lucid Lisp returns 1.
Symbolics Common Lisp returns 1.
Cost to Implementors:
Pretty small (one-line fix).
Cost to Users:
None.
Cost of non-adoption:
Continued embarassment for Steele.
Performance impact:
Negligible.
Benefits:
Correct handling of a seldom-used boundary case.
Esthetics:
Mild improvement.
Discussion:
Mentioned in Steele's December 1985 "clarifications".
∂08-Dec-88 1643 X3J13-mailer Issue: LAMBDA-FORM (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 16:43:41 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 16:29:39 PST
Date: 8 Dec 88 15:30 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: LAMBDA-FORM (Version 4)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-162939-4858@Xerox>
!
Forum: CLeanup
Issue: LAMBDA-FORM
References: LAMBDA (p59)
Related Issues: LISP-SYMBOL-REDEFINITION, PACKAGE-CLUTTER
Category: ADDITION
Edit history: 22-Jun-88, Version 1 by Pitman
16-Sep-88, Version 2 by Pitman
02-Oct-88, Version 3 by Pitman
22-Nov-88, Version 4 by Masinter
Problem Description:
In Scheme, one writes not #'(LAMBDA ...) but just (LAMBDA ...).
Many Common Lisp programmers have asked for this feature.
It can be written by the user, but since it's a commonly asked
for feature, it would make sense for it to be in the standard.
Also, even though the definition is trivial,
(DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))
it is difficult to offer this as an extension because then "portable
code" tries to define it, it will get a redefinition warning because
it will be clobbering the system's predefined definition.
[An implementation could shadow LAMBDA, but that, too, has associated
problems.]
Proposal (LAMBDA-FORM:NEW-MACRO):
Add a LAMBDA macro, which has equivalent effect to:
(DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))
Rationale:
This is an upward-compatible extension which ``codifies current
practice'' in that it makes a commonly defined macro available
as a standard part of the language.
Test Case:
#1: (DEFUN ADDER (N) (LAMBDA (X) (+ X N)))
(FUNCALL (ADDER 5) 3) => 8
#2: (MAPCAR (LAMBDA (X) (+ X 3)) '(1 2 3)) => (4 5 6)
#3: (MACROEXPAND '(LAMBDA (X) (+ X Y)))
=> (FUNCTION (LAMBDA (X) (+ X Y)))
Current Practice:
Symbolics Genera implements NEW-MACRO.
Symbolics Cloe does not offer a LAMBDA macro because users who defined
their own in portable code complained that they were getting redefinition
warnings that CLtL had led them to believe shouldn't happen. [Ironically,
the redefinition warnings always came when they tried to define LAMBDA
in the way it was already defined!]
Many other Common Lisp implementations do not offer such a macro.
Cost to Implementors:
The cost is trivial. A portable definition is shown in the
problem description above.
Cost to Users:
No conversion cost. This change is basically upward compatible.
Cost of Non-Adoption:
There are no really major consequences of non-adoption.
Benefits:
It's been suggested that some people write '(LAMBDA ...) rather than
#'(LAMBDA ...) because it's less ugly, and then run into confusion
later. If they could just write (LAMBDA ...), some that use overly
superficial reasons for the choice of one notation over another might
accidentally select the primitive they should probably really be using.
Aesthetics:
In Scheme, the operator of a function invocation form has the same
evaluation semantics as the operands. In CL, however, the operator is
not evaluated in the same way that the operands are. This definition
of LAMBDA as a macro would obscure this difference. A novice Lisp
programmer might have a hard time understanding why the #' is
optional in
(MAP [#'](LAMBDA (POINT) (+ (POINT-X POINT) (POINT-Y POINT)))
POINT-LIST)
but is required in
(MAP #'SUM-OF-COORDS POINT-LIST)
This proposal "clutters" the language because it makes the syntax
more complex. LAMBDA is then used not only as a "flag" for
introducing lambda-expressions, but also is a macro which generates
functions. There is at least one precedent for having two
operations that do the identical thing -- NOT and NULL. Both have
been retained because they express different intents. In this case,
the intent of #'xxx might be to ``access'' a function by name (the
name of an anoymous function being its lambda expression), and the
intent of (LAMBDA ...) is to ``create'' a function. This distinction
is subtle but may be expressionally interesting to some programmers
in some situations.
Notationally, some people believe strongly that (LAMBDA ...) looks
a lot better than #'(LAMBDA ...). Certainly it takes up fewer
characters, and (LAMBDA ...) is a notable offender in code needing
to be split onto multiple lines, so every little bit probably helps.
Discussion:
Numerous people have suggested this from time to time in the past,
but it's often been amidst a bunch of other more controversial issues.
Pitman wrote up this proposal and supports LAMBDA-FORM:NEW-MACRO.
Technically, CLtL does already permit implementations to predefine a
LAMBDA macro, but most argue that this leeway was accidental. CLtL
says that "all" functions, etc in CLtL must be in the LISP package,
but it does not say "all and only". This oversight leaves enough room
for implementors to add all manner of extra junk in the LISP package.
A separate cleanup item (LISP-SYMBOL-REDEFINITION) addresses
this issue.
An earlier revision of this proposal considered the alternative of
making this a new special form. Many people prefered that alternative.
However, there were also strong objections to requiring a new special form;
since the FUNCTION special form is still necessary (for #'symbol),
it was deemed better to have LAMBDA a macro which is defined
in terms of FUNCTION than to have both LAMBDA and FUNCTION
as special forms.
∂08-Dec-88 1716 X3J13-mailer Issue: LISP-SYMBOL-REDEFINITION (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 17:16:11 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 16:58:45 PST
Date: 8 Dec 88 16:42 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: LISP-SYMBOL-REDEFINITION (Version 5)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-165845-4914@Xerox>
!
Forum: Cleanup
Issue: LISP-SYMBOL-REDEFINITION
References: Cleanup issue PACKAGE-CLUTTER
CLtL pp 67-69 Defining named functions
Category: CLARIFICATION
Edit history: Masinter, Version 1, 17-Sep-88 from (Kolb, 14-Aug-87)
Masinter, Version 2, 7-Oct-88
Masinter, Version 3, 7-Oct-88, fix typos
van Roggen, Version 4, 13-Oct-88, undefined, not unspecified
Masinter, Version 5, 22-Nov-88, add more cases
Problem description:
Is it legal to redefine Common Lisp functions? There is no explicit
prohibition, and many implementations do allow redefinition of
functions in the Lisp package.
CLtL only says that special forms can not be redefined. But this doesn't
solve the general problem of redefining system functions.
Proposal LISP-SYMBOL-REDEFINITION:DISALLOW
This proposal uses the phrase "the consequences are undefined" in the
sense that implementations may signal an error, or other undefined behavior
may ensue, and attempts to specify that user programs generally cannot
portably modify the behavior of the symbols in the LISP package.
For example, programming environments may warn the user about
redefinition of LISP symbols and then allow them. Some environments may
distinguish between functions that are safe to redefine and those that are
not.
Specify that the consequences of performing any of the following
operations are undefined:
* redefining as a function or macro any of the functions,
macros, or special forms defined in the LISP package;
* lexically defining (with FLET, LABELS or
MACROLET) any function or macro in the LISP package;
* attempting to rebind any symbol in CL defined as a constant;
this covers binding as with LET or LAMBDA, assignment
as with SETQ or SETF, or using MAKUNBOUND;
(implied by CLtL p. 69)
* defining type-specifiers as with DEFTYPE, DEFSTRUCT, or
DEFCLASS, any of the built in type specifiers, classes;
* defining or redefining SETF macros or functions of any
of the functions, macros or special forms that have specified
SETF behavior, using either DEFSETF or DEFINE-SETF-METHOD
(or with DEFUN if the proposal under SETF-FUNCTION-VS-MACRO
is adopted);
* applying TRACE to any function in the LISP package.
No other restrictions are placed on users attaching definitions
on symbols in the LISP package; for example, a user program
may
(DEFVAR CAR 3)
Examples:
The behavior of the construct:
(FLET ((OPEN (filename &key direction) (format t "Open called....")
(OPEN filename :direction direction)))
(with-open-file (x "frob" :direction ':output)
(format t "was Open called?")))
is undefined; for example, the macro expansion of with-open-file might refer
to the OPEN function and might not.
(DEFUN CAR (X) (CDR X))
might signal an error.
Rationale:
This proposal is the only simple resolution of the problem description that
we can imagine that is consistent with current implementation techniques.
Allowing arbitrary redefinition of symbols in the LISP package would place
severe restrictions on implementations not to actually use those symbols in
macro expansions of other LISP symbols, in function calls, etc. While some
looser restrictions might do for any particular Common Lisp implementation,
there seems to be no good way to distinguish between those symbols that are
redefinable and those that are not.
In general, programs can redefine functions safely by creating new symbols in
their own package, possibly shadowing the name.
Current practice:
Many Lisp environments have some mechanism for warning about redefinition of
Lisp symbols and preventing accidental redefinition while allowing it where
necessary (e.g., to patch the Lisp system itself, fix a bug, add an
optimization.)
Fewer check for lexical redefinition, since such redefinition is not as
dangerous. Certainly, there are some symbols that are never used in macro
expansions of the standard Common Lisp macros. However, implementations do
differ on the behavior of macro expansions.
Cost to Implementors:
This proposal clarifies the status quo -- that the consequences are undefined. It
allows and encourages implementors to check for such redefinition, but does not
require it.
Cost to Users:
This proposal clarifies that implementations are free to check for a condition
that they might not have before, and may clarify that some current user code is
non-portable.
Benefits:
This issue frequently arises. Adopting this proposal would clarify a frequent
source of question about Common Lisp.
Cost of non-adoption:
Continued questions.
Esthetics:
Disallowing all redefinition is the simplest way of disallowing the ones that
really are trouble.
Discussion:
There have been various proposals for allowing users to extend the "protection"
mechanism to their own macros, functions, packages. These proposals seem like
they are environment issues and not language ones, however.
It is unfortunate that the restriction on reusing LISP package symbols in
FLET, LABELS or MACROLET is necessary, but the research into straightening out
the syntactic environment of macroexpansion isn't mature enough to put into
a standard yet.
∂08-Dec-88 1739 X3J13-mailer Issue: NTH-VALUE (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 17:39:03 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 17:20:41 PST
Date: 8 Dec 88 17:15 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: NTH-VALUE (Version 4)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-172041-4997@Xerox>
!
Issue: NTH-VALUE
References: Multiple values, pp. 133-139
Category: ADDITION
Edit history: 16-Aug-88, Version 1 by Pierson
01-Oct-88, Version 2 by Pitman (minor edits)
5-Oct-88, Version 3 by Masinter
(add Current Practice as per Gray)
8-Dec-88, Version 4 by Masinter
(add comments to discussion)
Problem description:
The set of operations on multiple values in Common Lisp is incomplete:
The only ways to retrieve just one of several return values (other than
the first) are:
- Bind several variables and then ignore all but one.
eg, (MULTIPLE-VALUE-BIND (X Y Z) <exp> (DECLARE (IGNORE X Y)) Z)
This is somewhat cumbersome to write and not perspicuous.
- Get a list of all return values and select from that.
eg, (THIRD (MULTIPLE-VALUE-LIST <exp>))
This is somewhat cumbersome, not perspicuous, and creates
needless garbage.
Proposal (NTH-VALUE:ADD):
Add a new macro NTH-VALUE, described as
NTH-VALUE n form [Macro]
Evaluates the FORM and returns the Nth value returned by the form as
a single value. N is 0-based, i.e. the first returned value is
value 0 (for consistency with NTH and NTHCDR). Both N and FORM are
evaluated, in left-to-right order.
Examples:
With this proposal MOD could be defined as:
(DEFUN MOD (NUMBER DIVISOR)
(NTH-VALUE 1 (FLOOR NUMBER DIVISOR)))
The same code would currently be:
(DEFUN MOD (NUMBER DIVISOR)
(MULTIPLE-VALUE-BIND (DIVIDEND REMAINDER)
(FLOOR NUMBER DIVISOR)
(DECLARE (IGNORE DIVIDEND))
REMAINDER))
Rationale:
This corrects the stated problem.
Current practice:
The TI Explorer and LMI Lambda have this feature.
Cost to Implementors:
Writing the macro version is fairly straightforward.
Some will choose to implement compiler hooks so that code written with
NTH-VALUE will be as efficient as possible. This may involve some
additional work, but presumably nothing major.
Cost to Users:
This is an upward-compatible change.
Cost of non-Adoption:
The occassional code where this comes up may be one or more of
clumsier to write, more difficult to read, or less efficient.
(The feature is rarely used in implementations that have it.)
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
While it does add another function to the language it removes
some need for the hairier multiple-value forms.
Discussion:
Pitman proposed this in the very late pre-CLtL days. It was
rejected then because it was too late in the cycle.
There was not strong sentiment for including this feature
in Common Lisp, but no active opposition.
Comments at the October 1988 X3J13 meeting:
"Trivial, gratuitous."
"Not trivial -- allows index computation. Hard to do this
in a portable, efficient way."
"Says he has an NTH-VALUE macro for a portable system that he
uses (which exploits the computed index feature) and that it's
a gross kludge in one implementation to make it efficient."
∂08-Dec-88 1750 @Score.Stanford.EDU:tom@polya.Stanford.EDU Printer ELM down
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Dec 88 17:50:25 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 8 Dec 88 17:48:33-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA25796; Wed, 7 Dec 88 11:34:34 PDT
Date: Wed, 7 Dec 88 11:34:34 PDT
From: Tom Dienstbier <tom@polya.Stanford.EDU>
Message-Id: <8812071934.AA25796@polya.Stanford.EDU>
To: csd@score, faculty@score
Subject: Printer ELM down
The printer ELM in room 433 will be down for 2 hours to fix a high
usage of toner problem.
tom
∂08-Dec-88 2041 X3J13-mailer Issue: PACKAGE-DELETION (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 20:41:45 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 20:40:59 PST
Date: 8 Dec 88 20:40 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: PACKAGE-DELETION (Version 5)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-204059-5304@Xerox>
!
Forum: Cleanup
Issue: PACKAGE-DELETION
References: Packages (pp171-192), PACKAGE-NAME (p184), PACKAGEP (p76)
Category: ADDITION
Edit history: 30-Sep-88, Version 1 by Pitman
01-Oct-88, Version 2 by Pitman
04-Oct-88, Version 3 by Pitman
(provide for correctable errors in some cases)
07-Oct-88, Version 4 by JonL
21-Nov-88, Version 5 by Masinter
Problem Description:
There is no way to get rid of a package in Common Lisp.
This absence makes interactive development work tricky in some
implementations. If a package is accidentally built incorrectly, the
user must either rename the package to another package or start over
by reloading his program in a fresh lisp image.
Some programs need to create and destroy packages at runtime.
Without such a facility, some clumsy combination of RENAME-PACKAGE,
UNINTERN, and UNUSE-PACKAGE is usually made to work. However, it is
easy for a casual programmer to forget to undo some of the
bookkeeping, leading to unwanted effects.
Proposal (PACKAGE-DELETION:NEW-FUNCTION):
Introduce the function DELETE-PACKAGE, described as follows:
DELETE-PACKAGE package [Function]
Deletes PACKAGE from all package system data structures. PACKAGE may
be either a package or the name of a package.
If PACKAGE is a package name (i.e., not type PACKAGE) which does not
currently name a package, a correctable error is signalled. If
continued, no deletion action is attempted. Instead, DELETE-PACKAGE
immediately returns NIL.
If PACKAGE is a package object (i.e., an object of type PACKAGE)
which has already been deleted, no error is signalled and no further
deletion action is attempted. Instead, DELETE-PACKAGE immediately
returns NIL.
If the designated package is used by other packages, a correctable
error is signalled. If continued, the effect of UNUSE-PACKAGE is
done to remove any dependencies, causing its external symbols to stop
being accessible to those packages. Once this is done, DELETE-PACKAGE
goes on to delete the package just as it would had there been no
packages that used it.
After this operation completes, the contents of the symbol-package
slot of any symbol homed in the deleted package is unspecified; for
those symbols not homed in that package, the contents remain unchanged.
Except for this, symbols in the deleted package are not modified in
any other way.
The effect of DELETE-PACKAGE is that the name and
nicknames of the designated package cease to be recognized package
names. The package object is still a package -- PACKAGEP is true
of it -- but PACKAGE-NAME will return NIL. The effect of any other
package operation on PACKAGE once it has been deleted is undefined.
In particular, FIND-SYMBOL, INTERN and other functions that
look for a symbol name in a package will have unspecified results if
called with *PACKAGE* bound to the deleted package or with the
deleted package as an argument.
DELETE-PACKAGE returns T if the deletion attempt was successful
and NIL otherwise.
Examples:
(SETQ *FOO-PACKAGE* (MAKE-PACKAGE "FOO" :USE NIL))
(SETQ *FOO-SYMBOL* (INTERN "FOO" *FOO-PACKAGE*))
(EXPORT *FOO-SYMBOL* *FOO-PACKAGE*)
(SETQ *BAR-PACKAGE* (MAKE-PACKAGE "BAR" :USE '("FOO")))
(SETQ *BAR-SYMBOL* (INTERN "BAR" *BAR-PACKAGE*))
(EXPORT *FOO-SYMBOL* *BAR-PACKAGE*)
(EXPORT *BAR-SYMBOL* *BAR-PACKAGE*)
(SETQ *BAZ-PACKAGE* (MAKE-PACKAGE "BAZ" :USE '("BAR")))
(SYMBOL-PACKAGE *FOO-SYMBOL*) => #<Package "FOO">
(SYMBOL-PACKAGE *BAR-SYMBOL*) => #<Package "BAR">
(PRIN1-TO-STRING *FOO-SYMBOL*) => "FOO:FOO"
(PRIN1-TO-STRING *BAR-SYMBOL*) => "BAR:BAR"
(FIND-SYMBOL "FOO" *BAR-PACKAGE*) => FOO:FOO, :EXTERNAL
(FIND-SYMBOL "FOO" *BAZ-PACKAGE*) => FOO:FOO, :INHERITED
(FIND-SYMBOL "BAR" *BAZ-PACKAGE*) => BAR:BAR, :INHERITED
(PACKAGEP *FOO-PACKAGE*) => T
(PACKAGEP *BAR-PACKAGE*) => T
(PACKAGEP *BAZ-PACKAGE*) => T
(PACKAGE-NAME *FOO-PACKAGE*) => "FOO"
(PACKAGE-NAME *BAR-PACKAGE*) => "BAR"
(PACKAGE-NAME *BAZ-PACKAGE*) => "BAZ"
(PACKAGE-USE-LIST *FOO-PACKAGE*) => ()
(PACKAGE-USE-LIST *BAR-PACKAGE*) => (#<Package FOO>)
(PACKAGE-USE-LIST *BAZ-PACKAGE*) => (#<Package BAR>)
(PACKAGE-USED-BY-LIST *FOO-PACKAGE*) => (#<Package BAR>)
(PACKAGE-USED-BY-LIST *BAR-PACKAGE*) => (#<Package BAZ>)
(PACKAGE-USED-BY-LIST *BAZ-PACKAGE*) => ()
(DELETE-PACKAGE *BAR-PACKAGE*)
Error: Package BAZ uses package BAR.
If continued, BAZ will be made to unuse-package BAR,
and then BAR will be deleted.
Type :CONTINUE to continue.
Debug> :CONTINUE
=> T
(SYMBOL-PACKAGE *FOO-SYMBOL*) => #<Package "FOO">
(SYMBOL-PACKAGE *BAR-SYMBOL*) is unspecified
(PRIN1-TO-STRING *FOO-SYMBOL*) => "FOO:FOO"
(PRIN1-TO-STRING *BAR-SYMBOL*) is unspecified
(FIND-SYMBOL "FOO" *BAR-PACKAGE*) is undefined
(FIND-SYMBOL "FOO" *BAZ-PACKAGE*) => NIL, NIL
(FIND-SYMBOL "BAR" *BAZ-PACKAGE*) => NIL, NIL
(PACKAGEP *FOO-PACKAGE*) => T
(PACKAGEP *BAR-PACKAGE*) => T
(PACKAGEP *BAZ-PACKAGE*) => T
(PACKAGE-NAME *FOO-PACKAGE*) => "FOO"
(PACKAGE-NAME *BAR-PACKAGE*) => NIL
(PACKAGE-NAME *BAZ-PACKAGE*) => "BAZ"
(PACKAGE-USE-LIST *FOO-PACKAGE*) => ()
(PACKAGE-USE-LIST *BAR-PACKAGE*) is undefined
(PACKAGE-USE-LIST *BAZ-PACKAGE*) => ()
(PACKAGE-USED-BY-LIST *FOO-PACKAGE*) => ()
(PACKAGE-USED-BY-LIST *BAR-PACKAGE*) is undefined
(PACKAGE-USED-BY-LIST *BAZ-PACKAGE*) => ()
Rationale:
This facility corrects the deficiency described in the problem description.
Current Practice:
Symbolics has a function PKG-KILL which satisfies the proposed behavior
except that an error is not signalled if the package is used.
When a package is killed by PKG-KILL, the home package of all symbols
in that package are left undisturbed (i.e., local symbols pointing to
the killed package); this aspect is compatible with the stated proposal.
Procyon Common Lisp has a function called DELETE-PACKAGE already. It
returns the name of the package so deleted (as a string). [Perhaps it also
differs in the correctability of the errors it signals?]
Lucid Common Lisp implements DELETE-PACKAGE, except that the continuation
option for a name that doesn't name a package is different.
Cost to Implementors:
The cost of providing this facility is probably small.
Cost to Users:
Very slight to none. This change is essentially compatible.
Some code which cached packages in variables might have to be slightly
more cautious, but experience in the Symbolics implementation suggests
that it's really the responsibility of the person doing the DELETE-PACKAGE
to take care of worrying about the effects of having deleted the package:
normal programs need not bother testing a package for validity (using
PACKAGE-NAME) before using it.
Cost of Non-Adoption:
Getting rid of a package would continue to be difficult to do portably.
Benefits:
Better control of storage usage would be available portably.
Aesthetics:
No significant effect.
Discussion:
This was discussed as part of a larger bulk issue of how to undo all
sorts of definitions. Since that proposal has not gone anywhere
(perhaps bogged down under its own weight), this subtopic has been
broken off for separate discussion.
Note that if a symbol's package component is modified as a result
of being "unintern'd" from a delete packaged, then it is unspecified
as to how it will be printed.
∂09-Dec-88 0039 X3J13-mailer Issue: RETURN-VALUES-UNSPECIFIED (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 00:39:40 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 00:38:45 PST
Date: 9 Dec 88 00:38 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: RETURN-VALUES-UNSPECIFIED (Version 6)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-003845-5561@Xerox>
!
Issue: RETURN-VALUES-UNSPECIFIED
References: CLOSE (p 332), IN-PACKAGE (p 183), RENAME-PACKAGE (p 184),
TRACE (p 440), UNTRACE (p 440), INSPECT (p 442),
SET-SYNTAX-FROM-CHAR (p 361),
LOCALLY (p 156), PROVIDE (p 188), REQUIRE (P 188)
Related issues: REQUIRE-PATHNAME-DEFAULTS
CLOSED-STREAM-OPERATIONS
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
19-Sept-88, Version 2 by Chapman
6-Oct-88, Version 3 by Masinter
7-Oct-88, Version 4 by Masinter
26-Nov-88, Version 5 by Masinter
9-Dec-88, Version 6 by Masinter
Problem Description:
The descriptions of CLOSE, IN-PACKAGE, RENAME-PACKAGE, TRACE, UNTRACE,
INSPECT, SET-SYNTAX-FROM-CHAR, LOCALLY, PROVIDE, and REQUIRE
are not clear about the values returned from those constructs.
Proposal (RETURN-VALUES-UNSPECIFIED:SPECIFY)
Clarify that the return values for the listed constructs are as follows:
CLOSE -- T
IN-PACKAGE -- the new package, i.e. the value of *PACKAGE* after the
execution of IN-PACKAGE.
RENAME-PACKAGE -- the renamed package.
TRACE (when called with arguments) -- implementation-dependent.
UNTRACE -- implementation-dependent.
INSPECT -- implementation-dependent.
SET-SYNTAX-FROM-CHAR -- T
LOCALLY -- the return values of the last form of its body, i.e. the body is
surrounded by an implicit PROGN.
PROVIDE -- implementation-dependent.
REQUIRE -- implementation-dependent.
(NB: the issue CLOSED-STREAM-OPERATIONS proposes modifying
the return value of CLOSE on closed streams. The issue
REQUIRE-PATHNAME-DEFAULTS proposes removing
REQUIRE and PROVIDE. Those proposals would take
priority over this one.)
Rationale:
This clarification allows users to know when they can and can not
count on the values returned from these constructs.
Current Practice:
Varies; the choices made here are consistent with many but
not all implementations.
Cost to Implementors:
Small.
Benefits:
This clarification will assist users in writing portable code.
Cost to users:
Small; it seems unlikely that there is much code that currently
depends on the return values of these functions; such code isn't
portable.
Aesthetics:
Specified is better than not, when it makes sense.
Discussion:
PROVIDE and REQUIRE are not likely to appear except in the "top level" of
files, and so their return value is possibly moot. Another proposal would
eliminate them from the language, and then their return value would definitely
be moot!
There is some sentiment for leaving unspecified the values of the
debugging/environment features such as TRACE and UNTRACE,
for the same reasons that so much else of their behavior is unspecified.
Notes from Oct 88 X3J13:
Except for LOCALLY, why bother?
That just causes portability problems. Don't want to leave it
unspecified -unless- someone can cite a reason to do so.
"If many weren't defined, maybe we should leave 'em, but
since nearly all -are- defined, let's just go ahead and
round out the set."
Most text books she's seen show CLOSE returning NIL.
One text book shows it returning T.
Since some people like to think of T as success and NIL
as failure, maybe it should always return T.
(See Issue: CLOSED-STREAM-OPERATIONS.)
∂09-Dec-88 0057 X3J13-mailer Issue: SETF-FUNCTION-VS-MACRO (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 00:57:39 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 00:56:50 PST
Date: 9 Dec 88 00:56 PST
From: masinter.pa@Xerox.COM
Subject: Issue: SETF-FUNCTION-VS-MACRO (version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
line-fold: NO
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <881209-005650-5575@Xerox>
This is a very difficult issue.
This writeup was distributed at the November 1987 meeting,
and at the October 1988 meeting.
There is another writeup, labelled Issue: SETF-PLACES which
will follow.
The following comments have not been incorporated into
this poposal:
Instead of generalizing SYMBOL-FUNCTION, add FDEFINITION and leave
SYMBOL-FUNCTION alone.
Do not modify TRACE and UNTRACE. Leave them implementation-dependent.
!
Issue: SETF-FUNCTION-VS-MACRO
References: SETF rules for what -place- can be (pp.94-7)
COMPILE function (p.438)
DEFUN macro (p.57)
DISASSEMBLE function (p.439)
DOCUMENTATION function (p.440)
FBOUNDP function (p.90)
FLET special form (p.113)
FMAKUNBOUND function (p.92)
FTYPE declaration (p.158)
FUNCTION special form (p.87)
FUNCTION declaration (p.159)
INLINE declaration (p.159)
NOTINLINE declaration (p.159)
LABELS special form (p.113)
SYMBOL-FUNCTION and setf of symbol-function (p.90)
TRACE macro (p.440)
UNTRACE macro (p.440)
Category: ADDITION
Edit history: Version 1, 13-Oct-87 Moon
(based on discussion among the CLOS working group)
Version 2, 26-Oct-87 Masinter, minor mods
Version 3, 4-Nov-87 Moon, small clarifications at KMP's urging
PROBLEM DESCRIPTION:
The Common Lisp Object System needs a well-defined way to relate the
name and arguments of a setting function to those of a reading function,
because both functions can be generic and can have user-defined methods.
We tried to hide the name and arguments of the setting function with
macrology, but the complexity got out of hand. It seems better to make
this information explicit; the version of the CLOS specification that
assumes the adoption of proposal SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
is much simpler in the relevant areas.
PROPOSAL (SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS):
Add to Common Lisp the concept of "setf functions". Right now, Common
Lisp only has "setf macros", which are defined by define-setf-method and
both forms of defsetf. Terminology:
- a "setf macro" is something that produces code (or other
specifications, as in define-setf-method) which, when evaluated,
will perform the effect of an invocation of setf.
- a "setf function" is something that is called to perform
directly the effect of an invocation of setf.
The form (setf (-name- ...) ...), when -name- is defined as a function
(rather than a macro) and no setf macro has been defined for -name-,
expands into a call to a setf function. The name of this setf function
is a list (setf -name-), where -name- is a symbol. The body of this
function is surrounded by an implicit block named -name-.
The functions, macros, special forms, and declarations defined in CLtL
and listed in the References section above need to be enhanced to accept
such lists in addition to symbols as function names, so that setf
functions can be defined and manipulated.
A setf function receives the new value to be stored as its first
argument. Thus, #'(setf foo) should have one more required parameter
than #'foo, the first required parameter is the new value to be stored,
and the remaining parameters should be the same as #'foo's parameters.
A setf function must return its first argument, since setf is defined
to return the new value.
A definition of a setf function can be lexically local, like a
definition of a reading function. The following rules specify the
behavior of SETF; note that these rules are ordered and the first rule
to apply supersedes any later rules. These rules are a consistent
extension of the current behavior of Common Lisp and the Cleanup
committee's resolution of issue GET-SETF-METHOD-ENVIRONMENT. Only
rule 4 is new with this proposal.
Rules for the macroexpansion of (setf (foo x) y):
(1) If the function-name foo refers to the global function definition,
rather than a locally defined function or macro, and if there is a
setf macro defined for foo, use the setf macro to compute the expansion.
(2) If the function-name foo is defined as a macro in the current scope,
use macroexpand-1 to expand (foo x) and try again.
(3) If the function-name foo is defined as a special form in the current
scope, signal an error.
(4) Expand into the equivalent of
(let ((#:temp-1 x) ;force correct order of evaluation
(#:temp-2 y))
(funcall #'(setf foo) #:temp-2 #:temp-1))
Note that rule 4 is independent of the scope of the function name
(setf foo). It does not matter if that scope is different from the
scope of the function name foo. This allows some nonsensical programs
to be written, but does not seem harmful enough to justify making more
complicated rules to compare the scopes of the two function definitions.
The above rules are actually implemented by GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE, rather than by the SETF macro itself.
Thus GET-SETF-METHOD generates the appropriate five values for a form
that is not a macro-invocation and does not have a defined setf macro.
Normally one does not define both a setf function and a setf macro
for the same reading function.
Normally one defines a local reading function and a local setf function
together in a single FLET or LABELS.
In the absence of any setf macro definition, SETF of a function expands
into a call to the setf function. This means that the setf function
only needs to be defined at run time, not compile time.
What CLtL says about (documentation foo 'setf) will not change.
Specifically, the setf documentation type applies just to defsetf (and
define-setf-method, that's an omission in CLtL). The documentation for
a setf function, as for any function, is retrieved by
(documentation '(setf foo) 'function).
Examples:
;If SETF of SUBSEQ was not already built into Common Lisp,
;it could have been defined like this
(defun (setf subseq) (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value j))))
;Another example, showing a locally defined setf function
(defun frobulate (mumble)
(let ((table (mumble-table mumble)))
(flet ((foo (x)
(gethash x table))
((setf foo) (new x)
(setf (gethash x table) new)))
..
(foo a)
..
(setf (foo a) b))))
;get-setf-method could implement setf functions by calling
;this function when rules 1-3 do not apply
(defun get-setf-method-for-setf-function (form)
(let ((new-value (gensym))
(temp-vars (do ((a (cdr form) (cdr a))
(v nil (cons (gensym) v)))
((null a) v))))
(values temp-vars (cdr form) (list new-value)
`(funcall #'(setf ,(car form))
,new-value ,@temp-vars)
`(,(car form) ,@temp-vars))))
RATIONALE:
By making the names and arguments of setting functions explicit, CLOS is
considerably simplified. In addition, this can supersede any proposals
to introduce a lexically local form of defsetf; lexically local setf
functions serve the same needs.
Current code that resembles
(defsetf foo |setf FOO|)
(defun foo (x) ..)
(defun |setf FOO| (x new) ..)
or
(defsetf foo internal-foo-setter)
(defun foo (x) ..)
(defun internal-foo-setter (x new) ..)
can be, but is not required to be, replaced with the following code
(defun foo (x) ..)
(defun (setf foo) (new x) ..)
An advantage of this is that several disparate styles of using
DEFSETF can be replaced with a single common style of using
setf functions, making programs more standardized and readable.
CURRENT PRACTICE:
A few Common Lisp implementations already have a similar feature,
in that they allow setting functions named (SETF reader). We don't
know of any implementation that has precisely the proposed feature.
ADOPTION COST:
The main cost is generalization of a few functions to accept lists
beginning with SETF where they now accept only symbols. Implementations
must add a data structure to store the function definition of a setf
function, however, this can trivially be done with property lists or
generated symbols.
The cost of making the SETF macro expand into a call to a setf function,
when it does not find a setf macro or a regular macro to expand, is
negligible.
This will be an incompatible change for Symbolics, since it already has
setf functions but they do not take the same arguments as proposed here.
However, the change is considered worthwhile.
COST OF NON-ADOPTION:
Non-adoption of this proposal would be a significant roadblock to the
Common Lisp Object System. Some major rethinking of CLOS would be
required.
BENEFITS:
Allow CLOS to be defined without out-of-hand complexity.
Improve usability of SETF.
CONVERSION COST:
None, this is an upward-compatible change.
As with any language extension, some program-understanding programs may
need to be enhanced. A particular issue here is programs that assume
that all function names are symbols. They may use GET to access
properties of a function name or use EQ or EQL (perhaps via MEMBER or
ASSOC) to compare function names for equality. Such programs will need
improvement before they can understand programs that use the new
feature, but otherwise they will still work.
ESTHETICS:
SETF would be more esthetic, but less powerful, if it had only the
proposed setf functions and did not have setf macros. Such a major
incompatible change is of course out of the question; however, if setf
functions are stressed over setf macros, SETF will be much easier to
teach.
DISCUSSION:
Note that in Common Lisp, setf macro expansion is an operation on
function names, not on functions. It differs from some dialects of
Scheme, such as T, in this respect. This proposal does not attempt to
change that.
There was some concern about introducing the notion that the name of the
setf-function associated with FOO should be a list, (SETF FOO). This is
a considerable extension to the idea of a "function name", at least for
standard Common Lisp implementations that do not implement Lisp machine
style function-specs.
However, the CLOS unsuccessfully tried a number of alternatives.
Fundamentally the problem is that there has to be a name that the user
uses to define the thing and to talk about it. Trying to hide the name
just means you use a more obscure name, like an alternate syntax for
DEFUN or DEFUN-SETF. Another reason for making the name explicit is to
allow one to use FLET for the setf function -- something which would be
difficult if there is not a name-like entity that can be bound.
This proposal is not incompatible with other extensions to function
specifications present in some implementations.
The following related features were considered but are specifically
not being proposed at this time, since they are unnecessary for CLOS
and appear not to improve the simplicity and esthetics of the language:
a) Lexically local setf macros, that is, a cross between DEFSETF and
MACROLET. This does not appear to be logically necessary. Would all
three ways of defining lexically global setf macros need local
counterparts?
b) Define the meaning of defmacro or macrolet of (setf foo)?
This would be a fourth way to define a setf macro.
c) Enhance the definition of global setf macros, for example to
say that (MACRO-FUNCTION '(SETF FOO)) returns an expander function
that takes two arguments and returns five values.
d) Introduce a new name for SYMBOL-FUNCTION, since it accepts
non-symbols now.
e) Should one allow these extended function names in the car-position
of an expression to be evaluated? The extra complexity didn't seem
justified, instead, an explicit FUNCALL is required.
----- End Forwarded Messages -----
∂09-Dec-88 0059 X3J13-mailer Issue: SETF-PLACES (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 00:59:36 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 00:58:47 PST
Date: 9 Dec 88 00:58 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: SETF-PLACES (Version 1)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-005847-5576@Xerox>
The following is the emmendation of SETF-FUNCTION-VS-MACRO that was
discussed at the Fairfax meeting; it incorporates the suggestions
made there by Gregor, Bob Kerns, and myself. Eric Benson and Patrick
Dussud here at Lucid have also reviewed it.
I've started it out under a different issue name, since it is such
a drastic change; but I wouldn't object at all if someone wants it
to be just another version of SETF-FUNCTION-VS-MACRO.
-- JonL --
!
Issue: SETF-PLACES
References: SETF rules for what a place-specifier can be; CLtL pp.94-7
X3J13 88-002R:
Accessing Slots, Ch. 1 p.11
DEFGENERIC Ch. 2 pp.26-9
DEFMETHOD Ch. 2 pp.39-41
(SETF DOCUMENTATION) Ch. 2 pp.43-5
ENSURE-GENERIC-FUNCTION Ch. 2 pp.46-7
GENERIC-FLET Ch. 2 p.52
GENERIC-LABELS Ch. 2 p.55-6
WITH-ADDED-METHODS Ch. 2 pp.90-1
Related issues: SETF-FUNCTION-VS-MACRO
Category: ADDITION
Edit history: Version 1, 11-Nov-88, by JonL
Problem description:
Common Lisp explicitly refrains from giving names to accessor update
functions. The intent is that the macro SETF should shield the user
from ever having to know such names; the correlation between an accessor
name and its corresponding updator name, or updating code sequence, is
to be established by DEFSETF and DEFINE-SETF-METHOD. Update function
names like SET and RPLACA are retained primarily for backwards
compatibility. See CLtL p.93-4.
However, this is extremely inconvenient for CLOS programing. The rub
is that the functionality of an updator function must be specifiable
"in pieces", by incremental uses of DEFMETHOD distributed throughout
perhaps dozens of files. A single definition using either DEFSETF or
DEFINE-SETF-METHOD is not an acceptable constraint for this style.
A named, generic function is the CLOS interface for doing distributed
code specification.
Furthermore, it is not at all clear where a DEFSETF call for a generic
function should go. Should it be before the first DEFMETHOD on the
update function? should it be bundled into every such DEFMETHOD?
should it be bundled into ENSURE-GENERIC-FUNCTION? Clearly, the first
two options would violate the modularity CLOS has strived so hard to
achieve; and the third violates the optionality of ENSURE-GENERIC-FUNCTION.
The best choice would be to elide the DEFSETF call completely. Some
way is needed to designate an update function, without necessarily
doing a DEFSETF or DEFINE-SETF-METHOD first.
Additionally the simpler form of DEFSETF, which could be used for
almost all generic needs (e.g., slot updating), requires the new-
value argument to be the last argument to the update function.
But in order to be able to discriminate upon the class of the
new-value argument, it cannot be described simply as "last" --
it must come before any &optional and &key arguments. Thus there
is need for some other avenue whereby the new-value argument would
come, say, first in the argument list of the update function.
Finally, the CLOS specification X3J13 88-002R seems to imply
that the CLOS exterior syntax for function specifiers must be
implemented down in the innards of every conforming Lisp
implementation. There is a very large amount of resistance
in the X3J13 group, at present, to any proposal which requires
any non-symbols as ordinary function names; not only do people
object to code like (SYMBOL-FUNCTION '(SOME LIST)), but there
is great reluctance to carry out system-wide modifications to
all places that deal with function names (most of which now
presume that "name" means SYMBOL). Yet is the current opinion
of most of the CLOS subcommittee that the exterior CLOS interface
can be kept intact without requiring the underlying Lisp
implementation to support non-symbols as function names.
Proposal (SETF-PLACES:ADD-SETF-FUNCTIONS)
-- Specify that certain function names are reserved to be "SETF functions",
or "updator functions", for use by SETF expansions. The very existence
of such an updator function is implicitly similar to having done a
DEFSETF [or rather, a modified form of the simple DEFSETF, as explained
next below]. Every accessor function name is uniquely paired with such
an updator name, regardless of whether the updator name ever has a
functional definition. However, these functions do not replace any
previously defined SETF methods, nor override the place specifications
of CLtL section 7.2; they simply provide a default expansion for SETF,
as described below.
-- Specify that such a a SETF function must take one more argument than
its corresponding access function. Let <access-fn> and <update-fn>
be such a correlated pair; then when SETF is given a "place" that is
a call on <access-fn>, it expands into a call on <update-fn> that is
given all the arguments to <access-fn> and also, as its very first
argument, the new-value (which must be returned by <update-fn> as
its value). For example, suppose that ASET is the updator function
name corresponding to AREF. Then
(SETF (AREF a i1 i2 ... in) value)
could expand into
(ASET value a i1 i2 ... in)
-- Extend the set of valid "place specifiers" as defined on CLtL p.94-7
by adding the following clause after all the existing ones:
For any other place specifier, the form
(SETF (<access-fn> A1 A2 ... AN) NEW-VALUE)
will expand into a call to the uniquely-named updator function
corresponding to <access-fn>, that is to the function named by
(UNDERLYING-NAME '(SETF <access-fn>)).
Note that SETF will no longer signal any "unknown place specifier"
errors during macroexpansion, because the default behavior is to
simply construct a call to the setf function [except, however, when
"access-fn" isn't legal as the name of a function; for example,
(setf ((spaz) i1 i2) value) is still syntaticly illegal]. But if
at run time, the "setf function" still hasn't been defined as a
function [such as by DEFUN, DEFMETHOD, setf of SYMBOL-FUNCTION etc.],
then a run-time "undefined function" error may occur.
Note also that not every SETF method for an accessor function can be
defined using an updator function. For example, LDB cannot be handled
this way, even if its corresponding update name is a defined function;
LDB must be handled by DEFINE-SETF-METHOD, and as such the prior rules
of CLtL p.94-7 would apply.
-- Be reminded that the rules for interpreting SETF place specifiers
are actually embodied in the functions GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE, rather than in the SETF macro
itself. Thus these two functions must be altered to reflect the new
"place specifier" called for just above. Since the rules on p.94-7
of CLtL are to be applied in order, then SETF functions will only be
used when no SETF "method" has been defined for the name, such as by
calling DEFINE-SETF-METHOD or DEFSETF; also, a macro definition for
the access name will block the use of the SETF function, since the
macro call must be expanded first. Remember also that such a updator
name may have a lexically local definition, as well as (or in addition
to) a global one.
-- Add a new function, UNDERLYING-NAME of one argument; and also add an
inverse for this function, UNDERLYING-NAME-TO-SPEC of one argument.
UNDERLYING-NAME is defined as:
(i) on any list like (SETF <name>), it returns a unique,
implementation-dependent name suitable for actual use as
a function name in that implementaion.
(ii) on symbols, it is the identity function; and
(iii) on any other data, it is undefined; however, other lists
like (<spec-kind> ...) should be reserved for extensions
which the x3J13 committee may be considering.
UNDERLYING-NAME-TO-SPEC is defined as:
(i) on any argument which specifically is the output of part (i)
above [i.e., an "underlying" name], it returns (SETF <name>);
thus the argument is the unique name which is EQUAL to
(UNDERLYING-NAME '(SETF <name>)).
(ii) on any symbol or list not covered by part (i) just above, it
returns it's argument.
(iii) on any other data, it is undefined; however, other lists
like (<spec-kind> ...) should be reserved for extensions
which the x3J13 committee may be considering.
The reason EQUAL is the determiner of "uniqueness" above is that it
is EQ for symbols; and for implementations which have "function specs"
it permits non-EQ copies of (SETF <name>) to be used interchangably.
The result of UNDERLYING-NAME should be constant across "incarnations"
of the same release of an implementation, and should be of a data type
that can be printed out and read back in reliably.
Thus in one implementation, which uses only symbols to name functions,
it might be that:
(UNDERLYING-NAME '(SETF FOO)) ==> SETF:4.USER.FOO
(UNDERLYING-NAME-TO-SPEC 'SETF:4.USER.FOO) ==> (SETF FOO)
whereas in another implementation, which has LispMachine style
"function specs", it would be that:
(UNDERLYING-NAME '(SETF FOO)) ==> (SETF FOO)
(UNDERLYING-NAME-TO-SPEC '(SETF FOO)) ==> (SETF FOO)
-- Alter all the above-referenced documentation in the CLOS specification
so as not to imply that lists are suitable as function names. In
particular,
(a) phrases like "... if <function-specifier> names a function" should
be changed to a phrase like "... if <function-specifier> refers to
a defined function", or possibly even something like
"... if (UNDERLYING-NAME <function-specifier>) names a function"
(b) phrases like "(FBOUNDP <function-specifier>)" should be changed
into "(FBOUNDP (UNDERLYING-NAME <function-specifier>))"; or
else other terminology should express the intent of what is to
be said. For example, instead of saying: "When (FBOUNDP <f-s>)
is true ..." one could just as well say "When <f-s> refers to
a defined function ..." The choice of which of these two formats
to use is an editorial one.
(c) phrases like "(SYMBOL-FUNCTION function-specifier)" should be changed
into "(SYMBOL-FUNCTION (UNDERLYING-NAME <function-specifier>))";
or else other terminology should express the intent of what is to
be said. For example, one might say "... the function referred
to by <f-s>". The choice of which of these two formats to use is
an editorial one.
Since the concept of a standard expansion for DEFMETHOD has been
accepted, then it is clear that a form like
(DEFMETHOD (SETF FOO) ...)
will expand exactly the same as
(DEFMETHOD #.(UNDERLYING-NAME '(SETF FOO)) ...)
The underlying call to ADD-METHOD will see the real function name used
for the updator function. The user-level interface of CLOS can still
present the list format as acceptable; it is only the implementation of
DEFMETHOD, DEFGENERIC, that will have to worry about converting to a
"real" name.
One expected use of UNDERLYING-NAME-TO-SPEC is in Lisp-level debuggers,
which could try to print out something more user-comprehensible than
the very internal names that an implementation might use in place of
function specs.
Examples:
;;; If CLtL did not already prescribe a SETF expansion for SUBSEQ calls,
;;; it could be defined like this:
(setf (symbol-function (underlying-name '(setf subseq)))
#'(lambda (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value i)))))
or, for implementations that have "function specs", this could be writen:
(defun (setf subseq) (new-value sequence start &optional end)
. . .)
;;; Here's an example using a local function. First, define
;;; MIDDLE-REF to be an accessor function as follows. [Assume
;;; also that MIDDLE-REF's home package is BAR.]
(defun middle-ref (vec i)
(check-type i fixnum)
(aref vec (ceiling i 2)))
;;; Now let SETF:3.BAR.MIDDLE-REF be the (implementation-dependent)
;;; updator function name corresponding to MIDDLE-REF; a normal
;;; definition of an update function for MIDDLE-REF could be:
(defun setf:3.bar.middle-ref (new-element vec i)
(check-type i fixnum)
(setf (aref vec (ceiling i 2)) new-element))
;;; But the SETF below will call FILL, because of the local definition
;;; of SETF:3.BAR.MIDDLE-REF; and nowhere have we have made any
;;; explicit call to DEFSETF or DEFINE-SETF-METHOD for MIDDLE-REF.
(flet ((setf:3.bar.middle-ref (new-element vec i)
;;"wide-body" version of set-middle-ref
(declare (ignore i))
(fill vec new-element :end (ceiling i 2))))
(setf (middle-ref "abc" 1) #\z))
;;; The following function could be called by GET-SETF-METHOD, to
;;; implement SETF functions, when none of the other rules of CLtL
;;; p.94-7 apply.
(defun get-setf-method-for-setf-functions (form)
(let* ((new-value (gensym))
(temp-vars (do ((a (cdr form) (cdr a))
(v nil (cons (gensym) v)))
((null a) v)))
((access-fn (car form)))
((update-fn (underlying-name `(SETF ,access-fn)))))
(values temp-vars
(cdr form)
(list new-value)
`(,update-fn ,new-value ,@temp-vars)
`(,access-fn ,@temp-vars))))
;;; For those implementations using "function specs", the form:
;;; `(,update-fn ,new-value ,@temp-vars)
;;; would probably have to be replaced by:
;;; `(FUNCALL #',update-fn ,new-value ,@temp-vars)
Rationale:
The paragraphs of the "Problem description:", except for the first,
describe four major problems with the status quo -- three concerning
the unsuitability of current SETF methods for supporting the CLOS
generic style, and one for an unintended presumption that every
implementation of CL will have "function specs". This proposal
corrects these problems, without adding any significant new ones.
Current practice:
Some implementations have "function specs", so that forms like
(SETF FOO) are permitted to name functions; but none have extended
the setf place specifiers as proposed herein.
Cost to Implementors:
Basically, none. Implementations which already have Lisp Machine
style "function specs" can just define UNDERLYING-NAME and
UNDERLYING-NAME-TO-SPEC as the identity function. For those without
such capabilities, there is a portable implementation listed in the
discussion section.
Extending GET-SETF-METHOD etc. to handle SETF functions should be a
very modest task at most.
Cost to Users:
This is basically an upward-compatible addition, so there should be
no cost to users [at least not for correct programs -- incorrect
SETF expansions will no longer be signalled at macroexpand time,
but may simply result in a runtime error for undefined function.]
Cost of non-adoption:
Non-adoption of this proposal would be a significant setback for the
Common Lisp Object System. There seems to be no agreeable alternative
for implementing generic setf methods.
Performance impact:
N.A.
Benefits:
See "Cost of non-adoption".
Esthetics:
This proposal increases the size of the definition of SETF; but
it greatly simplifies the "default" case, namely just defining
an updator function to correspond to an accessor.
Discussion:
The following code can be used by an implementation which doesn't
have "function specs" to implement the new functions:
;;;; -*- Mode: LISP; Syntax: Common-Lisp; Package: SYSTEM; Base: 10 -*-
;;;
;;; Author: JonL White, 15-Nov-88
;;;
(in-package "SYSTEM") ;or, your development package
(eval-when (eval compile load)
;;; The SETF package should be reserved for this purpose
;;;
(or (find-package "SETF")
(make-package "SETF" :use nil))
(defparameter *setf-package* (find-package "SETF"))
(unless (and (null (package-use-list *setf-package*))
(null (package-used-by-list *setf-package*)))
(error "SETF package has connections?"))
;;; "Internal Markers", to be used for uninterned symbols.
;;;
(export (intern "SETF-SPEC" *setf-package*) *setf-package*)
(export (intern "SETF-NAME" *setf-package*) *setf-package*)
)
(eval-when (eval compile)
(defmacro setf-spec-p (x)
(let ((spec (gensym)))
`(LET ((,spec ,x))
(AND (CONSP ,spec)
(EQ (CAR ,spec) 'SETF)
(CONSP (CDR ,spec))
(NULL (CDDR ,spec))
(SYMBOLP (SECOND ,spec))))))
)
(defun UNDERLYING-NAME (spec)
(cond
((symbolp spec)
spec)
((setf-spec-p spec)
(let* ((accessor (second spec))
(accessor-name (symbol-name accessor))
(home-package (symbol-package accessor)))
(if home-package
(let* ((package-name (package-name home-package))
;; 'spec-name' is a form like "~D.~A.~A", but FORMAT has a
;; problem with global print parameters like *print-radix*
(spec-name (concatenate 'string
(write-to-string (length package-name)
:radix nil :base 10 :length nil :level nil)
"."
package-name
"."
accessor-name))
(updator (or (find-symbol spec-name *setf-package*)
(let ((sym (intern spec-name *setf-package*)))
(export sym *setf-package*)
sym))))
;; A possible optimization, which trades off space for time, is
;; as follows; see definition of UNDERLYING-NAME-TO-SPEC below
;;(setf (get updator 'setf:setf-spec) (copy-list spec))
updator)
(or (get accessor 'setf:setf-name)
(let* ((uname (concatenate 'string "SET-" accessor-name))
(updator (make-symbol uname)))
(setf (get accessor 'setf:setf-name) updator)
(setf (get updator 'setf:setf-spec) (copy-list spec))
updator)))))
(t
(error "~S is an invalid arg for ~S" spec 'UNDERLYING-NAME))))
(defun UNDERLYING-NAME-TO-SPEC (x)
(cond
((not (symbolp x))
(if (setf-spec-p x)
x
(error "~S is an invalid arg for ~S"
x 'UNDERLYING-NAME-TO-SPEC)))
((get x 'setf:setf-spec))
(t
(let ((home-package (symbol-package x)))
(if (not (eq home-package *setf-package*))
x
(let ((name (symbol-name x))
accessor package-name)
;; Unpack the name, which is a form like "~D.~A.~A"
(multiple-value-bind (nchars starti)
(parse-integer name :radix 10 :junk-allowed t)
(incf starti)
(setq package-name (subseq name starti (incf starti nchars)))
(incf starti)
(setq accessor (find-symbol (subseq name starti)
(find-package package-name)))
(unless accessor
(error "~S failed to parse in ~S"
x 'UNDERLYING-NAME-TO-SPEC))
`(SETF ,accessor))))))))
----- End Forwarded Messages -----
∂09-Dec-88 0119 X3J13-mailer Issue: FUNCTION-DEFINITION (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 01:19:19 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 01:11:17 PST
Date: 9 Dec 88 01:10 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: FUNCTION-DEFINITION (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-011117-5596@Xerox>
!
Issue: FUNCTION-DEFINITION
References: Issue FUNCTION-TYPE
Category: ADDITION
Edit history: 23-Jun-88, Version 1 by Pitman
09-Dec-88, Version 2 by GZ (change name, remove REQUIRED
option, specify first value to be a lambda, add to
discussion and current practice)
Problem Description:
There are portable ways to turn symbols and lists into functions,
but there are no portable ways to get back the original symbols and
lists given the functions.
In many cases, it used to be possible to recover the lambda expression
after a DEFUN by using FUNCTION or SYMBOL-FUNCTION, but the passage of
FUNCTION-TYPE will make this no longer be the case.
Proposal (FUNCTION-DEFINITION:FUNCTION-SOURCE):
Introduce a new function called FUNCTION-SOURCE which takes as
its argument a function and returns three values:
#1: The function's defining lambda expression, or NIL if the information
is not available. The lambda expression may have been pre-processed
in some ways, but it should remain a suitable argument to COMPILE
or FUNCTION.
#2: NIL if the definition was enclosed in the null lexical
environment or something non-NIL if the definition might
have been enclosed in some non-null lexical environment.
#3: the `name' of this function. The name is intended for debugging
only and may be any lisp object -- not necessarily one that would
be valid for use as a name in DEFUN or FUNCTION, for example.
By convention, NIL is used to mean that the function had no name.
Implementations are free to always return NIL T NIL, but are encouraged
to return the lambda expression in the case where the argument was created
by an in-core call to COMPILE or EVAL (as opposed to being created by
loading a compiled file).
Examples:
The following examples illustrate some possible return values, but
are not intended to be exhaustive:
#1: (FUNCTION-SOURCE #'(LAMBDA (X) X))
or (FUNCTION-SOURCE (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), NIL, NIL
#2: (FUNCTION-SOURCE (FUNCALL #'(LAMBDA (X) #'(LAMBDA () X)) NIL))
might return NIL, T, NIL
or (LAMBDA () X), T, NIL
but -not- (LAMBDA () X), NIL, NIL
#3: (DEFUN FOO (X) X)
(SETF (SYMBOL-FUNCTION 'BAR) #'FOO)
(FUNCTION-SOURCE #'BAR)
might return NIL, NIL, NIL
or (LAMBDA (X) (BLOCK FOO X)), T, NIL
or (LAMBDA (X) (BLOCK FOO X)), NIL, FOO
or (SI::BLOCK-LAMBDA FOO (X) X), NIL, FOO
#4: (DEFUN FOO ()
(FLET ((BAR (X) X))
#'BAR))
(FUNCTION-SOURCE (FOO))
might return NIL, T, NIL
or (LAMBDA (X) (BLOCK BAR X)), T, NIL
or (LAMBDA (X) (BLOCK BAR X)), T, (:INTERNAL FOO 0 BAR)
or (LAMBDA (X) (BLOCK BAR X)), NIL, "BAR in FOO"
Rationale:
This functionality would be useful to a pretty printer, debugger,
inspector, and other tools.
Cost to Implementors:
The following implementation is technically legitimate, although many
implementations would want to provide something more useful:
(DEFUN FUNCTION-SOURCE (FUNCTION)
(CHECK-TYPE FUNCTION FUNCTION)
(VALUES NIL T NIL))
Current Practice:
Many implementations record this information, but not all that do
publish an interface to extracting the information. VAXLISP and
Lucid call it SOURCE-CODE. Coral calls it UNCOMPILE-FUNCTION.
The language T has this operation and calls it DISCLOSE. It is the
conceptual inverse of the ENCLOSE which occurs in some Scheme dialects,
and is implemented as what CLOS would call a "generic function".
Cost to Users:
None. The change is upward compatible.
Cost of Non-Adoption:
Certain kinds of portable debugging tools would be harder to write.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
The phrase ``program is data; data is program'' comes up a lot in discussions
about Lisp. This makes the case for ``program is data'' more interesting.
Discussion:
The initial name proposed for this function was FUNCTION-DEFINITION. This
was changed because of technical uses of the term ``definition'' to refer
to the entire defining form (e.g. a DEFUN form) rather than the lambda
expression that might be recovered from it.
The possibility of _requiring_ the lambda expression to be available for
all functions created by in-core calls to COMPILE or FUNCTION was considered
but didn't receive much support. Pitman would prefer that option because
it is considerably more useful in practice, but would like to see at least
the current proposal.
∂09-Dec-88 0133 X3J13-mailer Issue: STREAM-ACCESS (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 01:32:55 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 01:31:00 PST
Date: 9 Dec 88 01:30 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: STREAM-ACCESS (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-013100-5620@Xerox>
!
Issue: STREAM-ACCESS
References: streams (Chapter 21 of CLtL)
Category: ADDITION
Edit History: 17-Jun-88, version 1 by Walter van Roggen
30-Nov-88, version 2 by Masinter
Problem Description:
There are many components of streams which are specified upon creation
but are not accessible afterwards. Furthermore there is no way in
Common Lisp to determine the type of a stream to see if it has particular
components, or even if it is OPEN.
The accessors wanted are those associated with broadcast streams,
concatenated streams, echo streams, file streams, string streams,
synonym streams, two way streams.
There are three proposals, which differ only by the whether
they include types, type predicates, or both, in addition to
the stream component acessors. Ballots can be either for
one of the proposals or none. (Other combinations of, say,
accessors without either predicates or types, or types without
accessors, do not seem reasonable and are not being proposed
at this time.)
Proposal STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
First, add a function to determine whether a stream is "OPEN":
OPEN-STREAM-P stream [Function]
Returns T if a stream is open, NIL if it is closed. It is an error
if the argument is not a stream.
Streams are "open" until they have been closed with
CLOSE, or, the dynamic context of the creating/accessing
macros of WITH-OUTPUT-TO-STRING, WITH-OPEN-FILE,
WITH-INPUT-FROM-STRING, WITH-OPEN-STREAM,
have been exited.
There are three kinds of things to add associated with each kind of
stream: data types, predicates, accessors.
Stream data types:
BROADCAST-STREAM (returned by MAKE-BROADCAST-STREAM)
CONCATENATED-STREAM (returned by MAKE-CONCATENATED-STREAM)
ECHO-STREAM (returned by MAKE-ECHO-STREAM)
FILE-STREAM (returned by OPEN or created by WITH-OPEN-FILE)
STRING-STREAM (returned by MAKE-STRING-INPUT-STREAM,
MAKE-STRING-OUTPUT-STREAM, and created by WITH-INPUT-FROM-STRING
and WITH-OUTPUT-TO-STRING and FORMAT with second argument NIL)
SYNONYM-STREAM (created by MAKE-SYNONYM-STREAM)
TWO-WAY-STREAM (created by MAKE-TWO-WAY-STREAM)
The stream data types are all subtypes of type STREAM and are mutually
exclusive. (In particular, a synonym stream is only of type SYNONYM-STREAM.)
Stream Predicates:
Each of these returns T if the object is of the corresponding type,
and NIL otherwise.
BROADCAST-STREAM-P, CONCATENATED-STREAM-P,
ECHO-STREAM-P, FILE-STREAM-P, STRING-STREAM-P,
SYNONYM-STREAM-P, TWO-WAY-STREAM-P
Note that the predicates do not "follow the link" of a synonym
stream.
Stream Informational Functions:
BROADCAST-STREAM-STREAMS broadcast-stream ==> list of streams
This function returns a list of output streams that constitute
all the streams the broadcast stream is broadcasting to. It is
an error if the argument is not of type BROADCAST-STREAM.
CONCATENATED-STREAM-STREAMS concatenated-stream ==> list of streams
This function returns a list of input streams that constitute
the ordered set of streams the concatenated stream still has to
to read from, starting with the current one it is reading from.
The list may be () if no more streams remain to be read.
It is an error if the argument is not of type CONCATENATED-STREAM.
ECHO-STREAM-INPUT-STREAM echo-stream ==> input-stream
ECHO-STREAM-OUTPUT-STREAM echo-stream ==> output-stream
These functions return the corresponding component stream. It is
an error if the argument is not of type ECHO-STREAM.
SYNONYM-STREAM-SYMBOL synonym-stream ==> symbol
This function returns the symbol whose SYMBOL-VALUE the
synonym stream is using. It is
an error if the argument is not of type SYNONYM-STREAM.
TWO-WAY-STREAM-INPUT-STREAM two-way-stream ==> input-stream
TWO-WAY-STREAM-OUTPUT-STREAM two-way-stream ==> output-stream
These functions return the corresponding component stream. It is
an error if the argument is not of type TWO-WAY-STREAM.
Proposal: STREAM-ACCESS:ADD-TYPES-ACCESSORS
Identical to ADD-TYPES-PREDICATES-ACCESSORS except to leave out the
stream type predicates.
Proposal: STREAM-ACCESS:ADD-PREDICATES-ACCESSORS
Identical to ADD-TYPES-PREDICATES-ACCESSORS except to not
identify new data types. The accessors act as if the types were specified
(i.e., are mutually excusive).
Current Practice:
VAX LISP implements ADD-TYPES-PREDICATES-ACCESSORS.
We have not surveyed other implementations.
Cost to Implementors:
All of the proposals are reasonably simple to implement, since the information
must be present for nearly all types.
Cost to Users:
The proposals are upward-compatible, and should have little impact.
Cost of Non-Adoption:
The benefits would not be available in a portable fashion.
Benefits:
Programs would be able to access useful information otherwise hidden.
Discussion:
This issue has come up frequently, particularly dealing with SYNONYM-STREAMs.
The behavior of OPEN-STREAM-P on, for example, broadcast streams, might
be specified in a variety of alternative ways. This specification seems the simplest.
There are three proposals for voting because there was no agreement at the
October X3J13 on the issue of whether types, predicates, or both should be
added.
There was a proposal at one time to add a new function FOLLOW-SYNONYM-STREAM
which could be written as
(defun follow-synonym-stream (x)
(if (synonym-stream-p x)
(follow-synonym-stream (symbol-value (synonym-stream-symbol x)))
x))
i.e., which chases through zero or more synonym stream indirections.
∂09-Dec-88 0119 X3J13-mailer Re: Issue: SETF-FUNCTION-VS-MACRO (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 01:19:24 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 01:13:30 PST
Date: 9 Dec 88 01:13 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: SETF-FUNCTION-VS-MACRO (version 3)
In-reply-to: masinter.pa's message of 9 Dec 88 00:56 PST
To: x3J13@Sail.Stanford.EDU
Message-ID: <881209-011330-5598@Xerox>
At the last meeting, our notes are that an amendment was offered and accepted:
" Remove SYMBOL-FUNCTION, TRACE and UNTRACE from the list of affected
functions.
Add a new function:
FDEFINITION <spec> [Function]
The current global function definition named by <spec> is returned.
It is an error if the <spec> has no function definition.
<spec> must be either a symbol or a list of the form (SETF <symbol>).
FDEFINITION may be used with SETF to alter the global function
definition.
"
This amendment was not been incorporated into Version 3.
∂09-Dec-88 1008 X3J13-mailer Issue: STREAM-INFO (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 10:07:50 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 10:03:19 PST
Date: 9 Dec 88 10:02 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: STREAM-INFO (Version 6)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-100319-6354@Xerox>
An amendment to this proposal is under consideration, to change
the following names:
LINE-WIDTH ==> STREAM-LINE-WIDTH
LINE-POSITION ==> STREAM-LINE-POSITION
PRINTED-WIDTH ==> STREAM-STRING-WIDTH
("PRINTED-WIDTH is misleadingly named (in my opinion) because the function PRINT
is not involved. STREAM-WRITTEN-WIDTH looks a little weird.)
!
Forum: Cleanup
Issue: STREAM-INFO
References: FORMAT ~T (pp398-9) and ~<...~> (pp404-6), PPRINT (p383)
Category: ADDITION
Edit history: 22-Jun-88, Version 1 by Pitman (2d model)
23-Jun-88, Version 2 by Waters (1d model, modified 2d model)
24-Jun-88, Version 3 by Pitman (minor reformatting)
24-Jun-88, Version 4 by Pitman (remove 2d model for submission)
23-Sep-88, Version 5 by Waters (cleaned up in response to
discussion)
30-Nov-88, Version 6 by Masinter (add discussion)
Problem Description:
Currently, there is no portable way to inquire about the line width of
an output stream, the current position on a line, or the amount of
space that the display of a string will take up. This makes it
essentially impossible to write a portable implementation of a pretty
printer.
Proposal STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS:
Introduce four new functions.
These functions are carefully designed with an eye to the way they
interact. As a result, they can only be defined fully in terms of
each other. The presentation below first gives a very brief
definition of each function and then gives detailed specifications of
their relationships.
LINE-WIDTH &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [Function]
Returns a number representing the line width available
when printing to OUTPUT-STREAM. If the stream has no meaningful
width (or the width cannot be computed) then NIL is returned.
LINE-POSITION &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [Function]
Returns a number representing the current horizontal
position on the current output line, or NIL if the position cannot
be computed.
WRITE-SPACE WIDTH &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [function]
Inserts blank space of length WIDTH into OUTPUT-STREAM. WIDTH must
be a non-negative number. WRITE-SPACE returns T if the operation
is successful and NIL otherwise (e.g., if the operation is not
supported by OUTPUT-STREAM).
PRINTED-WIDTH STRING &optional (OUTPUT-STREAM *STANDARD-OUTPUT*)
&key (START 0) (END NIL) [Function]
Returns a number representing the horizontal width that would be
required to display STRING if it were written at the current moment
to OUTPUT-STREAM using (WRITE-STRING STRING OUTPUT-STREAM :start
START :end END), or NIL if this width cannot be computed. The width
may be negative (e.g., if STRING contains backspace or newline
characters.)
PRINTED-WIDTH does not return any indication of the vertical
distance required when printing STRING. The START and END
parameters delimit a substring of STRING in the usual manner.
PRINTED-WIDTH never causes any change in the state of OUTPUT-STREAM.
The width returned may well depend on the current state of
OUTPUT-STREAM (e.g., the width of tabs depends on the line position
and the width of characters depends on the font in use.) In all
respects the width is computed based on the current state of the
stream. However, the width returned always assumes that the total
line width is infinite---i.e., does not reflect any wraparound or
truncation which might occur.
-The difficulties of a full specification:
The functions above are intended to solve a specific current problem
in CL. To serve this purpose, they must have reasonably precise
specifications. However, there are several things which make it
desirable to have specifications which allow for significant
variability between implementations. First, current implementations
of CL differ greatly in the way IO is supported, and overly strict
specifications might make things very difficult for certain
implementations. Second, CL places no limits on the kinds of
idiosyncratic characters which can be supported by particular
implementations. Third, while many CL implementations only support
the printing of characters in fixed width fonts, it is desirable to
allow for output streams that support variable width fonts.
Finally, it is desirable to leave room to move for the future.
-Operations on standard characters where the line-width has not yet been
exceeded.
To deal with the problems above, a layered specification is
provided. The lowest level specification is given in terms of
constraints between the four functions above. In this lowest level
specification, two key simplifying assumptions are made. First, it
is assumed that at the time the constraint applies, none of the
previous operations on the stream S in question have caused output
to go beyond the physical horizontal limits of the output device on
the output lines relevant to the constraints. I.e., it is assumed
that truncation and or wraparound of the output has not occurred on
these lines. Second, it is assumed that all of the characters
output to the stream on the output lines relevant to the constraints
are standard characters as defined in CLTL pp 20-21. The
non-standard character #\newline may have been used to end one line
and start the next. (Note that standard characters are all simple
characters such as A-Z. Particularly, #\tab, #\backspace,
#\newline, are NOT standard characters.) It is further assumed that
the strings (X and Y) referred to in the constraints consist solely
of standard characters.
Basic properties of LINE-POSITION:
1- For all S, (not (minusp (line-position S)).
2- For all S, (zerop (line-position (progn (terpri S) S))).
3- For all S, If something is at line position N on one line and
something else is at line position N on another line, then the
two things are lined up vertically one under the other.
Defining property of WRITE-SPACE
4- For all N,S, let M = (+ (line-position S) N)
if M <= (line-width S), then
(= (line-position (progn (write-space N S) S)) M)
Defining property of PRINTED-WIDTH
5- For all X,S, let M = (+ (line-position S) (printed-width X))
if 0 <= M <= (line-width S), then
(= (line-position (progn (write-string X S) S)) M)
Basic property of LINE-WIDTH
6- For all N,S, let P = (line-position S)
If (+ P N) <= (line-width S) then
(write-space N S) is guaranteed to output space on the end of
the current line without any truncation of wraparound occurring.
7- For all X,S, let P = (line-position S)
If 0 <= (+ P (printed-width X)) <= (line-width S) then
(write-string X S) is guaranteed to output X on the end of
the current line without any truncation of wraparound occurring.
Additional properties of PRINTED-WIDTH
8- For all X,Y (= (printed-width (concatenate 'string X Y) S)
(+ (printed-width X S) (printed-width Y S)))
9- For all X,Z (= (printed-width X S)
(progn (write-string Z S) (printed-width X S)))
-Support for varying width fonts.
A key motivation behind the functions above is dealing with
arbitrary kinds of output devices and output streams that support
variable width fonts. To provide for this, the properties above
place no absolute constraints on the units used for the width
values. In fact, the units can vary from stream to stream. The
only thing that is required is that for a given stream, the units
must be a constant throughout the life of the stream, and the four
functions above must all operate in terms of the same units. The
units should be chosen to be small enough to represent the minimum
possible difference in the length of two strings and large enough
that it is possible to perform (write-space 1). (I.e., a single
pixel is a logical choice.)
If an output stream only supports a single fixed width font, then
the logical width unit to choose is the width of a single character.
Given this choice, the following is a minimal implementation of the
four functions that meets the requirements above.
LINE-WIDTH returns the maximum number of characters which can be
printed on a single line. LINE-POSITION returns the number of
characters output since the last #\newline (or since the creation of
the stream if no #\newlines have been output). (WRITE-SPACE N S)
outputs N #\space characters. Finally, (PRINTED-LENGTH X S) =
(length X).
-Support for non-standard characters and situations where line width
has been exceeded.
In the main, the properties above can be supported even if the line
width has been exceeded and even when non-standard charactres are
involved. However, characters such as #\tab and #\newline can make
it impossible to support properties 7 and 8. In addition, when the
line width is exceeded, property 3 may not hold. It is hoped that
implementors will make a good faith effort to support the functions
in the full range of situations which can be encountered in their CL
implementations. However, the simple implementation suggested above
will probably provide at least 80% of the benefits intended. As a
result, it is important that people not allow the potential
difficulties of a full implementation deter them from making a
minimal implementation.
-Support for derivative streams.
Intentionally, very little is said about what the width units should
be or exactly what LINE-WIDTH should return. The only key criterion
is that LINE-WIDTH should return a result that is pessimistic enough
to ensure proper printing. However, it is useful to make some
comments about these matters with regard to certain types of
derivative streams.
If a synonym stream, two way stream, or echo stream is created, it
should have the same line-width and width unit as the base output
stream.
A string output stream should have a line-width of NIL and probably
should be treated as supporting a fixed width font and having an
output width unit so that each character has a printed-width of 1.
If a broadcast stream is created, then LINE-LENGTH, LINE-POSITION,
and PRINTED-WIDTH should be be supported by reflecting them through
to the FIRST base stream. (There is no guarantee that anything
reasonable can be done with the streams as a set. For example, one
might support a varying length font while the others don't.) An
attempt should be made to send WRITE-SPACE requests to all of the
base streams. However, they may not come out right on other than
the first base stream.
Test Case:
Suppose that S is an output stream that supports a single fixed
width font which can display 72 characters on a line and that the
associated width unit is the width of one character. Evaluating the
following will produce the results shown.
(line-width S) => 72
(terpri S) => nil
(output-position S) => 0
(printed-width "testing: " S) => 9
(write-string "testing: " S) => "testing: "
(line-position S) => 9
(write-string "foo" S) => "foo"
(terpri S) => nil
(write-space 9 S) => T
(write-string "bar" S) => "bar"
The output produced is
testing: foo
bar
Rationale:
Pretty printing requires the function LINE-WIDTH to know how wide the
output it produces can be. Pretty printing requires LINE-POSITION to
determine where on the line output is when pretty printing starts.
Pretty printing requires PRINTED-WIDTH to determine how much space
things will take in the output. (If a variable width font is being
used, this cannot be determined without a detailed knowledge of the
font being used.) (Properties 7 & 8 greatly reduce the number of
times PRINTED-WIDTH has to be called.) Pretty printing requires
WRITE-SPACE to get proper indentations. (If a variable width font is
being used, indentations may be required that cannot be obtained by
outputting spaces.)
Current Practice:
Essentially every implementation of Common Lisp must support the
minimal functionality above internally in order to support PPRINT and
the FORMAT directives ~T and ~<...~>. However, there is no documented
interface to this functionality in CLTL. As a result, while some
implementations of Common Lisp make this functionality available to
users, some do not. Further, the implementations that do provide
this functionality do so in a variety of incompatible ways.
Cost to Implementors:
This proposal is written in such a way as to allow implementations
which do not have the ability to compute difficult values to just
return NIL. Very little work is forced. The idea is to offer
implementors a common way to provide this useful information to
portable programs where possible.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Complex output programs such as pretty printers cannot be written
portably.
Benefits:
A wide range of programs can gain better control of the format of output.
Aesthetics:
No significant aesthetic impact other than a slight increase in the
number of functions defined.
Discussion:
This issue probably should have been called PRETTY-PRINT-WIDTH-SUPPORT.
Dick Waters (author of GPRINT, a portable pretty printer), originally
raised this issue.
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS is the minimum required to support
pretty printing into a stream which displays output using a variable width
font.
Originally the functions were defined to return integers; however, there
are some output devices (e.g., those that have arbitrary scaling
operations), for which it would be difficult to find a reasonable
least-common-denominator for line-width.
We considered an alternate proposal which goes significantly beyond what is
needed merely for pretty printing and provides primitives
LINE-DIMENSIONS, LINE-POSITION, PRINTED-DIMENSIONS, and WRITE-SPACE but
it is not included here. A key point of contention was the question of how
to handle the issue of vertical distance (where is the origin, which way
do you count, ...).
We considered requiring PRINTED-WIDTH to return two additional values:
the number of newlines that WRITE-STRING of the string would execute and
the maximum X position encountered (which might differ from the first value
if the number of newlines was non-zero).
This feature wasn't strictly necessary for pretty-printing, and so was
omitted.
Some of the draft proposals from the character committee contained some
proposed functions that were attempting to solve the same problem.
Conflicting proposals should be avoided.
∂09-Dec-88 1045 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Thanks
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Dec 88 10:45:09 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 9 Dec 88 10:41:35-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA09993; Fri, 9 Dec 88 10:40:36 PDT
Date: Fri, 9 Dec 88 10:40:36 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8812091840.AA09993@Tenaya.stanford.edu>
To: hayes-roth@sumex, genesereth@score
Cc: faculty@score
Subject: Thanks
Thanks, on behalf of the Department, to both of you for your efforts
at organizing and implementing CS300 this quarter. Barbara, I know
you devoted effort above and beyond the call of duty, and we all owe
you special thanks!
By copy of this message, I would like to solicit opinion from faculty
members who did not give a CS300 lecture about whether or not they
would like to do so if we continued CS300 into next quarter. It's an
excellent way to describe the sort of research you do to the
first-year PhD students. (Sharon Hemenway will forward this message
to the first-year PhD students to get their opinion on whether they
would like to hear more lectures.)
-Nils
∂09-Dec-88 1047 X3J13-mailer Issue: SYMBOL-MACROLET-DECLARE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 10:47:13 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 10:32:48 PST
Date: 9 Dec 88 10:32 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: SYMBOL-MACROLET-DECLARE (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-103248-6444@Xerox>
!
Issue: SYMBOL-MACROLET-DECLARE
References: SYMBOL-MACROLET (88-002R page 2-81)
WITH-ACCESSORS (88-002R page 2-88)
WITH-SLOTS (88-002R page 2-92)
Related Issues: SYMBOL-MACROLET-SEMANTICS
FLET-DECLARATIONS (passed)
Category: ADDITION
Edit history: Version 1, 12-Sep-88, Moon
Version 2, 9-Dec-88, Masinter
(add cross reference, discussion)
Problem description:
It would be both natural and nice to be able to write
(with-slots (rho theta) point
(declare (single-float rho theta))
...computation...)
Proposal (SYMBOL-MACROLET-DECLARE:ALLOW):
Allow declarations at the head of the body of SYMBOL-MACROLET, and hence
in WITH-ACCESSORS and WITH-SLOTS. Exactly the same declarations are
allowed as for LET, with one exception: SYMBOL-MACROLET signals an error
if a SPECIAL declaration names one of the symbols being defined as a
symbol-macrolet. A type declaration of one of these symbols is equivalent
to wrapping a THE expression around the expansion of that symbol.
Example:
See problem description.
Rationale:
If SYMBOL-MACROLET is intended to resemble LET in syntax, it ought to
allow declarations. When writing a SYMBOL-MACROLET directly, the user
could just as easily write a THE expression instead of a type
declaration. However, when invoking a macro such as WITH-SLOTS that
expands into SYMBOL-MACROLET, the user does not have this option since
the expansion is not supplied explicitly by the user.
Current practice:
SYMBOL-MACROLET was only tentatively added to Common Lisp 3 months ago.
Cost to Implementors:
Less than one man-hour.
Cost to Users:
None.
Cost of non-adoption:
Minor wart in the language.
Benefits:
More consistent language definition.
Esthetics:
More consistent language definition.
Discussion:
This issue is related to SYMBOL-MACROLET-SEMANTICS.
"A macro-definition for SYMBOL-MACROLET would leave the issue of
DECLARE open. But the special-form version of SYMBOL-MACROLET
really should address it."
∂09-Dec-88 1047 X3J13-mailer Issue: SYMBOL-MACROLET-SEMANTICS (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 10:47:26 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 10:40:52 PST
Date: 9 Dec 88 10:40 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: SYMBOL-MACROLET-SEMANTICS (Version 5)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-104052-6470@Xerox>
!
Issue: SYMBOL-MACROLET-SEMANTICS
References: SYMBOL-MACROLET (88-002R page 2-81)
Related Issues: SYMBOL-MACROLET-DECLARE
Category: CHANGE
Edit history: 29-July-88, Version 1 by Piazza
21-September-88, Version 2 by Piazza
22-September-88, Version 3 by Piazza
22-September-88, Version 4 by Piazza
30-Nov-88, Version 5 by Masinter
Problem Description:
The SYMBOL-MACROLET construct, introduced with CLOS in X3J13 document
88-002R, profoundly alters the interpretation of symbols appearing as
forms in a Common Lisp program--what previously was necessarily a variable
might now be a symbol macro instead. Macros which appear in the body of a
SYMBOL-MACROLET form are currently unable to determine whether a symbol
form is a variable or a symbol macro, and, if the latter, what the
expansion of the symbol macro is. Consequently, complex macros (such as
SETF or PUSH) which depend on the form of their argument(s), are unable to
produce their desired results in some cases, as in the following example:
(let ((a (make-array 5))
(i 0))
(symbol-macrolet ((place (aref a (incf i))))
(push x place))
i) ==> 2
Proposal (SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM):
Change the definition of SYMBOL-MACROLET to specify that it is a special
form, which affects the evaluation environment for symbols. Enhance
MACROEXPAND and MACROEXPAND-1 so that they can expand a symbol macro.
Modify SETF et al to use the new MACROEXPAND and MACROEXPAND-1 to examine
even symbol subforms. Specify that the expansion of a symbol macro IS
subject to further macro expansion in the same lexical environment as the
symbol macro invocation, exactly analogous to normal macros. Clarify that
within the body of a SYMBOL-MACROLET, SETQ of a symbol defined as
a symbol macro will be treated as if it were a SETF.
Rationale:
The potential for interaction between macros is exactly why &environment
arguments were originally added to macros. Changing SYMBOL-MACROLET to be
a special form, which communicates through the &environment arguments to
macros with MACROEXPAND and MACROEXPAND-1, would allow PUSH and SETF
(among others) to work with SYMBOL-MACROLET in the same way they work with
MACROLET.
This change cannot (reasonably) support the currently specified semantics
that the expansion text is "outside" the scope of the symbol macro. For
indeed, when the symbol macro is expanded, (a copy of) the expansion is
then within the scope of the SYMBOL-MACROLET, and should then be subject
to further scrutiny. The issue of "infinite expansion" of symbol macros is
no more dangerous than that of normal macros.
Current Practice:
Portable CommonLoops (PCL) provides a code-walking implementation of
SYMBOL-MACROLET as specified in 88-002R. Symbolics Cloe has both a
code-walking version of a SYMBOL-MACROLET macro and compiler support for
a SYMBOL-MACROLET special form.
Cost to Implementors:
If SYMBOL-MACROLET is modified to be a special form, compilers and
interpreters will have to change, as well as MACROEXPAND, MACROEXPAND-1,
PUSH, INCF, DECF, and others.
Cost to Users:
If SYMBOL-MACROLET is converted to a special form, code-walking programs
will have to be modified to handle SYMBOL-MACROLET correctly. Those same
programs would have to be modified to handle the other special forms
specified in CLOS, anyway.
Cost of Non-Adoption:
SYMBOL-MACROLET will retain its confusing semantics, leading to bugs when
it interacts with complex macros and forms which produce side-effects.
Implementations which support ONCE-ONLY will break. For that matter, any
mechanism which examines code and assumes that "variables" have no side
effects will break.
Benefits:
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM avoids the hairiest problems
surrounding interaction of macros (like SETF) and side effects, and makes
SYMBOL-MACROLET consistent with MACROLET.
Aesthetics:
If SYMBOL-MACROLET is made to be a special form, aesthetics are improved
by making symbol macros consistent with normal macros.
Discussion:
A case could be made for adding a new function, SYMBOL-MACRO-FUNCTION, as
a dual of MACRO-FUNCTION. However, symbol macros are simpler than normal
macros: a symbol macro is associated with a single expansion form, rather
than an arbitrary function which computes the expansion. For this reason,
the augmented MACROEXPAND-1 proposed here can also fill the role of
SYMBOL-MACRO-FUNCTION: the second value of (macroexpand-1 sym env) will be
T if and only if sym is a symbol macro, while the first value gives the
expansion of sym, if it has one.
Rather than extending the existing MACROEXPAND and MACROEXPAND-1
functions, new functions could be introduced to expand symbol macros.
However, there seems to be no particular reason to do this.
∂09-Dec-88 1338 LOGMTC-mailer Seminar in the Foundations of Mathematics
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Dec 88 13:38:31 PST
Received: by csli.Stanford.EDU (4.0/4.7); Fri, 9 Dec 88 13:35:29 PST
Date: Fri 9 Dec 88 13:35:28-PST
From: Paolo Mancosu <MANCOSU@CSLI.Stanford.EDU>
Subject: Seminar in the Foundations of Mathematics
To: phil-all@csli.Stanford.EDU, logic@csli.Stanford.EDU
Message-Id: <597706528.0.MANCOSU@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Seminar in Logic and Foundations
Speaker: Paolo Mancosu
Title: "Generalizing Classical and Effective Analogues for Model
Theory, Part II"
Time: Monday, Dec. 12, 4:15 pm
Place: Room 381-T, Math Bldg, Stanford
S. Feferman
-------
-------
∂09-Dec-88 1406 X3J13-mailer Issue: TAGBODY-CONTENTS (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 14:06:43 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 13:39:52 PST
Date: 9 Dec 88 13:39 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: TAGBODY-CONTENTS (Version 5)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-133952-701@Xerox>
!
Forum: Cleanup
Issue: TAGBODY-CONTENTS
References: TAGBODY (pp 130-131 of CLtL)
Category: CLARIFICATION
Edit History: 13-Sep-88, version 1 by Walter van Roggen
02-Oct-88, version 2 by Pitman
(beef up rationale, clarify tag NIL is ok)
04-Oct-88, version 3 by Pitman (fix wording bug)
05-Oct-88, version 4 by Pitman
(modify proposal based on comments from Peck@Sun
-- allow both (GO NIL) and unused duplicated tags)
9-Dec-88, Version 5 by Masinter (wording per Pitman)
Problem Description:
CLtL specifies that symbols and integers are valid tags
in a TAGBODY and that lists are valid forms in a TAGBODY
but is silent about other data types.
Also, NIL is both a symbol and a list. Some implementations
might permit (GO NIL) because they treat NIL as a tag,
while others might not permit because they treat NIL as a form.
Proposal (TAGBODY-CONTENTS:FORBID-EXTENSION):
A TAGBODY's body may contain arbitrary data elements; no
constraints are placed on duplication of those elements.
duplications. Elements that are lists (CONSP) are evaluated in
left-to-right order. Any other elements are ignored by TAGBODY. However,
GO is only legal when the given a tag that is a symbol or integer. The results
of executing GO when there is more than one instance of the same (EQL)
tag at the top level of the innermost TAGBODY containing that tag are
unspecified.
In particular it is an error to use a character, floating point number,
ratio or other data element as a tag to GO.
The same restrictions apply to all forms which implicitly use
TAGBODY, such as PROG and DO.
Examples:
;; legal, but useless
(TAGBODY 3.4 4.5 (print "hi there"))
;; not legal
(tagbody
(ecase char (#\a (go #\a)) (#\b (go #\b)))
#\a (print "Apple")
#\b (print "Ball"))
;;legal, even when args are NIL:
(defmacro foo1 (&rest args)
`(do () ((test-fn))
,(when (member :bar args) '(do-bar-thing))
,(when (member :baz args) '(do-baz-things))
(do-regular-things)))
;; legal, but bad style
(do (...)
(...)
-----
(...)
(...)
-----
(...))
Rationale:
The proposed set of tags is expressionally adequate.
Other candidate types have lurking problems that could
lead to subtle program bugs if permitted as tags. For example,
- Characters make bad tags because, for example,
(TAGBODY ... #\Return ... #\Newline ...)
will be an error in some implementations due to
(EQL #\Return #\Newline).
- Floats make bad tags because round-off error will vary
between implementations.
- Rationals have problems with reduction to lowest terms.
eg, (EQL 1/2 2/4). This doesn't vary between implementations
but may still cause surprises.
Duplicated tags are permitted in situations where no GO is done
to them; it is not our intent particularly to encourage the
practice. . But current practice is to permit such uses in
many implementations, and there was no driving
reason to force such code to break.
Current Practice:
Symbolics Genera documents that only symbols or integers are permitted.
The restriction is enforced by the compiler, but not the interpreter.
The TI Explorer permits using NIL as a GO tag, but as a special case,
does not warn about multiple appearances of NIL.
Many implementations allow duplicate tags if there is no GO to them.
Cost to Implementors:
A few simple checks are probably all that's needed. Probably most
implementations (both interpreters and compilers) already perform them.
Implementations that disallow duplicate tags (generally in the
compiler but not the interpreter) will have to remove the
error checks.
Cost to Users:
Unlikely to affect any portable code.
If there are implementations which support other objects as tags
(floats, for example), other (likely minor) changes will be
necessary.
Benefits:
One less place for portability problems to occur.
Aesthetics:
Makes the language description more precise.
Discussion:
This issue was first included in in ">GLS>clarifications.text"
of 12/06/85.
Historical Note (JonL, Steele):
The reason pdp10 MacLisp allowed numbers, including flonums,
as tags was that Ira Goldstein's LLOGO (a LOGO system
written entirely in Lisp) just used READ for the statement
numbers, and they looked like floats; e.g., 1.1, 1.2, ... etc.
∂09-Dec-88 1407 X3J13-mailer Caveat on "From: cl-cleanup..."
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 14:06:52 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 DEC 88 13:52:02 PST
Date: 9 Dec 88 13:50 PST
From: masinter.pa@Xerox.COM
Subject: Caveat on "From: cl-cleanup..."
To: X3J13@sail.stanford.edu
Message-ID: <881209-135203-1007@Xerox>
While many of the issues distributed for your consideration have been
considered at length, a significant percentage have had last-minute changes
with little or no review by other cleanup committee members.
The urgency of getting items ready for voting coupled with the vacation and
work schedules of cleanup committee members has caused more haste than
usual.
∂09-Dec-88 1417 JONES@Score.Stanford.EDU AI concentration
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Dec 88 14:17:31 PST
Received: from Score.Stanford.EDU by csli.Stanford.EDU (4.0/4.7); Fri, 9 Dec 88 14:15:41 PST
Date: Fri 9 Dec 88 14:15:58-PST
From: "H. Roy Jones" <JONES@Score.Stanford.EDU>
Subject: AI concentration
To: ssp-faculty@CSLI.Stanford.EDU
Message-Id: <12453131782.36.JONES@Score.Stanford.EDU>
An advisee of mine just came and asked me to approve the following 'AI'
concentration:
CS22 Programming in Lisp
SS150 Computational Linguistics I
Psych187 Computational Models of Cognition
CS157 Logic and Automated Reasoning
Ling227 Computational Linguistics II
I was shocked to hear that these courses could make up an AI concentration.
Lisp is a programming language course and all but a prereq for any work in AI.
The two computational linguistics courses would seem to better fit in a
linguistics concentration. The psych course is similarly something that
belongs in a psych concentration, although I wouldn't complain quite as
much about this one.
Finally, CS157 is a course we introduced primarily because Phil 160A was
too hard for our students and also because we desired a different emphasis,
ie the new title... Anyhow, this proposal includes CS157, which we waive
for students who have had Phil 160A, which of course he will, as a course
in his AI concentration???
Comments? Is this really so?
Roy
-------
∂09-Dec-88 1446 barwise@russell.Stanford.EDU Re: AI concentration
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Dec 88 14:46:51 PST
Received: from russell.Stanford.EDU by csli.Stanford.EDU (4.0/4.7); Fri, 9 Dec 88 14:44:44 PST
Received: from localhost by russell.Stanford.EDU (4.0/4.7); Fri, 9 Dec 88 14:48:08 PST
To: JONES@Score.Stanford.EDU
Cc: ssp-faculty@CSLI.Stanford.EDU
Subject: Re: AI concentration
In-Reply-To: Your message of Fri, 09 Dec 88 14:15:58 PST.
<12453131782.36.JONES@Score.Stanford.EDU>
Address: CSLI, Stanford University, Stanford, CA 94305 (415) 723-0110
Date: Fri, 09 Dec 88 14:48:06 PST
From: Jon Barwise <barwise@russell.Stanford.EDU>
Roy, I am not sure if this program fills the letter of the
requirement, since I do not have that here. But it does not satisfy
the spirit of it at all.
I would not think that either the programming course or the 157 should
be admitted. 157 is a real problem for us. I wish it did not exist,
was clearly a subset of 160A, since our students have to take that.
What I don't know is how much there is about automated deduction, and
whether the students would pick that up someplace else.
About the computational linguistics, I would think that could be part
of an AI concentration, but only if computational linguitistics were
going to be what the student does. This is largely done in cs
departments, not linguistics departments, and is usually considered
within AI.
The cognitiion course sounds like a substitute for a course that
rosenbloom used to teach jointly between cs and psych. I don't know
much about it.
Mainly: you should not approve any program that you do not think is a
substantive concentration that is in the student's best interest, in
terms of their long range goals. That is what we count on you for, so
I am glad you are on the alert for those who would try to sneak thru.
Jon
∂09-Dec-88 1527 helen@russell.Stanford.EDU AI concentration
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Dec 88 15:27:15 PST
Received: by russell.Stanford.EDU (4.0/4.7); Fri, 9 Dec 88 15:28:22 PST
Date: Fri 9 Dec 88 15:28:22-PST
From: Helen Nissenbaum <HELEN@CSLI.Stanford.EDU>
Subject: AI concentration
To: Jones@SCORE.STANFORD.EDU, barwise@CSLI.STANFORD.EDU
Cc: ssp-faculty@CSLI.Stanford.EDU
Message-Id: <597713302.0.HELEN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
B
Roy and Jon, The student in question stopped by my office just a few
minutes ago and was about as perplexed about his concentration as we
seem to be. I think he had no idea about how cs157 relates to phil160a
and in fact might have been working from an old curriculum where -- if
my memory serves me, we had CS157 as a requirement for the AI concentration.
About the LISP programming course: We do indeed have that one and the
basic Prolog programming course in our concentration so his selection was
perfectly "legal". I agree that we may want to rethink how to include
cs21 and cs22 in future curriculi. (My guess is that most AI students take
at least one of these courses in their concentrations) In the next
few weeks we'll need to begin working on next year's curriculum so we
should definitely get these issues on the agenda.
Finally, I agree wholeheartedly with Jon about taking a firm
role in helping students design a concentration. Many students have only the
vaguest idea about course content and how to put courses together to
make up a coherent concentration. Thanks for the alert.
Helen
-------
∂09-Dec-88 1531 X3J13-mailer Issue: TEST-NOT-IF-NOT (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 15:31:21 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 15:30:26 PST
Date: 9 Dec 88 15:26 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: TEST-NOT-IF-NOT (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-153026-1243@Xerox>
This issue has two proposals.
Some people have indicated that they will vote for
one of these only conditionally, e.g.,
"Yes, if you change "REMOVE" to "DEPRECATE" and define the
term "DEPRECATE" in a way that permits the retention of these
primitives for the near term with intent to phase them out
later."
!
Forum: Cleanup
Issue: TEST-NOT-IF-NOT
References: Functions offering a :TEST-NOT keyword:
ADJOIN (p276), ASSOC (p280), COUNT (p257), DELETE (p254),
DELETE-DUPLICATES (p254), FIND (p257),
INTERSECTION (p277), MEMBER (p275), MISMATCH (p257),
NINTERSECTION (p277), NSET-DIFFERENCE (p278),
NSET-EXCLUSIVE-OR (p278), NSUBLIS (p275), NSUBST (p274),
NSUBSTITUTE (p256), NUNION (p276), POSITION (p257),
RASSOC (p281), REMOVE (p253), REMOVE-DUPLICATES (p254),
SEARCH (p258), SET-DIFFERENCE (p278),
SET-EXCLUSIVE-OR (p278), SUBLIS (p274), SUBSETP (p279),
SUBST (p273), SUBSTITUTE (p255), TREE-EQUAL (p264),
UNION (p276);
Functions with "-IF-NOT" in their name:
ASSOC-IF-NOT (p280), COUNT-IF-NOT (p257),
DELETE-IF-NOT (p254), FIND-IF-NOT (p257),
MEMBER-IF-NOT (p275), NSUBST-IF-NOT (p274),
NSUBSTITUTE-IF-NOT (p256), POSITION-IF-NOT (p257),
RASSOC-IF-NOT (p281), REMOVE-IF-NOT (p253),
SUBST-IF-NOT (p273), SUBSTITUTE-IF-NOT (p255);
Related Issue: FUNCTION-COMPOSITION
Category: CHANGE
Edit history: 02-Oct-88, Version 1 by Pitman (just FLUSH-ALL)
05-Oct-88, Version 2 by Pitman (add option FLUSH-TEST-NOT)
Problem Description:
The -IF-NOT functions are functionally unnecessary.
The :TEST-NOT keywords are not only functionally unnecessary but
also problematic because it's not clear what to do when both :TEST
and :TEST-NOT are provided.
Many people think Common Lisp is more `bloated' than it needs
to be and these aspects of the language are commonly cited
specific examples.
Proposal (TEST-NOT-IF-NOT:FLUSH-ALL):
Remove all -IF-NOT functions (named above) from Common Lisp.
Remove the :TEST-NOT keyword from the Common Lisp functions which
currently provide them (named above).
Rationale:
This makes the language a bit simpler.
The removal of :TEST-NOT also makes the language easier to explain.
Cost to Implementors:
Very slight.
Some symbols would disappear from the LISP package but could
still be offered in proprietary packages if deemed important
enough.
Implementations could compatibly retain the :TEST-NOT keywords
for an interim period.
Proposal (TEST-NOT-IF-NOT:FLUSH-TEST-NOT):
Remove the :TEST-NOT keyword from the Common Lisp functions which
currently provide them (named above).
Rationale:
This makes the language a bit simpler and easier to explain.
Cost to Implementors:
Very slight.
Implementations could compatibly retain the :TEST-NOT keywords
for an interim period.
Current Practice:
Presumably no one has done this yet.
Cost to Users:
Some rewrites would be needed.
Those rewrites, which are already fairly simple, would be even
more simple if some form of the FUNCTION-COMPOSITION issue is
voted in -- in particular, the COMPLEMENT function which it
proposes would help enormously in this regard.
Cost of Non-Adoption:
Common Lisp would continue to be what some people feel is
"bigger than it needs to be".
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
Presumably this makes the language easier to teach.
Performance impact:
Very small; removing the :TEST-NOT keywords would
make the simple implementation of the functions that
used to have them slightly faster, but the resulting
code of the inner loop is likely to be much slower.
Discussion:
Many people objected strongly to both of these proposals --
they might have been a nice idea five years ago, but are
gratuitous incompatibilities now: incompatible changes with
insufficient payback.
Some of those objections might be tempered if some additional
changes were made to Common Lisp: adding a COMPLEMENT
function, or if there were a strategy to declare some parts of the
language "obsolete". Since these conditions haven't been done,
their objections stand.
Steele noted that one main reservation to FLUSH-ALL is that
he uses REMOVE-IF-NOT much more than REMOVE-IF.
This issue is related to FUNCTION-COMPOSITION, but is not
dependent on it. Some support the combination of FLUSH-ALL and
the NEW-FUNCTIONS part of FUNCTION-COMPOSITION in spite of
the incompatible change because of the aesthetic appeal.
Some people expressed their intention to vote for FLUSH-ALL
only if FUNCTION-COMPOSITION:NEW-FUNCTIONS.
It was noted that and
adding a #~ readmacro such that
(FIND-IF-NOT #'ZEROP '(0 0 3))
== (FIND-IF (COMPLEMENT #'ZEROP) '(0 0 3))
== (FIND-IF #~ZEROP '(0 0 3))
The modification of these functions is moot for those who
prefer to use extended LOOP macro/iteration constructs
in lieu of the sequence functions.
Several alternative names for REMOVE-IF-NOT were
suggested: KEEP-IF, ABSTRACT, FILTER. We did not
pursue these suggestions.
∂09-Dec-88 1605 X3J13-mailer Issue: TYPE-OF-UNDERCONSTRAINED (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 16:05:10 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 15:58:54 PST
Date: 9 Dec 88 15:58 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: TYPE-OF-UNDERCONSTRAINED (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-155854-1325@Xerox>
This issue arose during the discussion of issue
COERCE-INCOMPLETE, and was only recently cast as
a formal proposal in its own right.
!
Forum: Cleanup
Issue: TYPE-OF-UNDERCONSTRAINED
References: TYPE-OF (CLtL)
88-002R (Class-of)
88-005, p 43f, Condition system types
Related issues: SUBTYPEP-TOO-VAGUE
DATA-TYPE-HIERARCHY-UNDERSPECIFIED
FUNCTION-TYPE
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
COERCE-INCOMPLETE
Category: CLARIFICATION/CHANGE
Edit history: Version 1, 1-Dec-88, Masinter
Version 2, 9-Dec-88, Masinter
Problem description:
The specification of TYPE-OF in CLtL is so weak as to leave it
nearly useless, if any implementor actually took the specification
seriously.In particular, there are almost no constraints on the
value that TYPE-OF might return for any of the built in
types. The only constraint placed is that for objects created by the
constructor function of DEFSTRUCT, the result of TYPE-OF is the name of the
defstruct.
This means that implementations could return T for all other objects.
Proposal (TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS):
Specify that the result of TYPE-OF satisfies the following:
(a) For any object for which (typep object built-in-type) is true when
built-in-type is one of
INTEGER, RATIO, FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, COMPLEX, NUMBER
SYMBOL,
STRING, VECTOR, ARRAY,
CONS,
STREAM, PACKAGE, CHARACTER, FUNCTION, READTABLE, HASH-TABLE, PATHNAME,
CONDITION, RESTART,
the result of TYPE-OF will be a type specifier for which
(subtypep (type-of object) built-in-type) returns T T, i.e., either the
build-in-type or a subtype of it (a subtype that the
implementation's SUBTYPEP can recognize.)
(b) For all objects, (TYPEP object (TYPE-OF object)) will be true.
(this implies that it will not be NIL, since no
object is of type NIL.)
(c) will be a MEMBER type specifier, or T.
For objects created by the "constructor" function of a structure
defined with DEFSTRUCT without a :TYPE option, TYPE-OF
will return the structure name.
For objects created by MAKE-INSTANCE, giving a named
class, TYPE-OF will return the class name of the class.
For objects which are instances of anonymous classes (i.e., where
(CLASS-NAME (CLASS-OF object)) is NIL), the result of TYPE-OF should be the
class object itself.
(The CLOS specification has already specified that class objects are
acceptable wherever type specifiers are, and in particular, as input to
SUBTYPEP and TYPEP.)
This proposal is intended to be consistent with 88-002R,
and not to conflict with any of the definitions in that document.
Examples:
It is legal for (TYPE-OF "abc") to return (SIMPLE-STRING 3), or just
STRING. It is legal for (TYPE-OF 112312) to return SI:MEDIUM-SIZE-FIXNUM,
as long as (SUBTYPEP 'SI:MEDIUM-SIZE-FIXNUM 'INTEGER).
Given:
(defvar *foo* (make-array 5 :element-type t))
(class-name (class-of *foo*)) => SIMPLE-VECTOR
It is legal for
(type-of *foo*) => (SIMPLE-VECTOR 5)
Rationale:
The original specification for "TYPE-OF" was written to allow
implementation freedom, but the wording is in fact more vague than was
intended.
Current practice:
Most Common Lisp implementations seem to implement the proposal, at least
for the types we've tried them on.
Cost to Implementors:
Even if there are implementations that do not currently implement the
proposal, the required changes for them are likely to be minimal.
Cost to Users:
Apparently none.
Cost of non-adoption:
TYPE-OF would remain potentially inconsistent.
Performance impact:
Likely none.
Benefits:
Bring the specification of TYPE-OF in like with its common
implementation, while requiring it to be generally useful.
Esthetics:
Little effect.
Discussion:
Originally, TYPE-OF was concieved as being useful for information display.
CLOS specified CLASS-OF far more precisely, in that it must return exactly
the class of an object. Unless TYPE-OF is removed from the language, it
seems reasonable to require it to be at least as precise as CLASS-OF.
The accepted CLOS specification does not define CLASS-OF
in terms of TYPE-OF, but an earlier draft did.
This proposal presumes the (passed) proposals
DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT, FUNCTION-TYPE, and
accomodates the Condition System (version 18) and CLOS.
If ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS does not pass,
and this proposal does pass, it may be that the only way an
implementation can satisfy (TYPEP array (TYPE-OF array))
would be to have (TYPE-OF array) return VECTOR or ARRAY
as appropriate, i.e., with no element type qualification.
It is possible to constrain TYPE-OF further, e.g., to eliminate
the possibility that it might return a non-portable
implementation-specific value. For example,
(TYPE-OF 112312) should not return SI:MEDIUM-SIZE-FIXNUM, but rather some
thing like (SIGNED-BYTE 17) [if that's what SI:MEDIUM-SIZE-FIXNUM means.]
We would like to make this as an implementation recommendation,
however, rather than as a constraint, at this point.
∂09-Dec-88 1618 X3J13-mailer Issue: VARIABLE-LIST-ASYMMETRY (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 16:17:57 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 16:17:10 PST
Date: 9 Dec 88 16:16 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: VARIABLE-LIST-ASYMMETRY (Version 3)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-161710-1373@Xerox>
!
Issue: VARIABLE-LIST-ASYMMETRY
References: CLtL pgs. 110, 122, 131
Category: ADDITION
Edit history: 26-Jul-88, Version 1 by Skona Brittain
04-Aug-88, Version 2 by Skona Brittain
08-Oct-88, Version 3 by Pitman
Problem Description:
The syntax of items in the variable-list for various control structues
(do, do*, let, let*, prog, prog*, and compiler-let) varies. This
variation seems unnecessary.
The allowed variations are indicated in the following chart:
do & do*: (var) (var init) (var init step)
prog & prog*: var (var) (var init) n.a.
let & let*: var (var val) n.a.
compiler-let var (var value)
Note that just plain `` var '' is prohibited in do forms
and that the case of ``(var)'' is prohibited in let forms
and compiler-let forms.
Proposal (VARIABLE-LIST-ASYMMETRY:SYMMETRIZE):
Allow all the variations in all of the forms;
i.e. add the prohibited cases mentioned above.
I.e. change the variable-list in the syntax descriptions as follows:
do & do*: ( { var | (var [init [step]] ) }* )
let & let*: ( { var | (var [value] ) }* )
compiler-let: ( { var | (var [value] ) }* )
Test Cases:
(let (a (b) (c 3)) ... ) would be valid.
(let* (a (b) (c 3)) ... ) would be valid.
(do (a (b) (c 3)) ... ) would be valid.
(do* (a (b) (c 3)) ... ) would be valid.
(compiler-let (a (b) (c 3)) ... ) would be valid.
Rationale:
The asymmetry is unnecessary and impedes learning of CL.
Any other way to make these cases consistent, such as either
omitting just ``var'' from do & do* and prog & prog*, or
omitting ``(var)'' from let & let* and prog & prog*,
would be an incompatible change to the language.
This way just adds the flexibility found in some of the forms to all of them.
Current Practice:
KCL allows ``(var)'' in let & let* but not ``var'' in do & do*.
Symbolics Genera allows all three cases in all the forms; i.e. it conforms
to this proposal.
Cost to Implementors:
Extremely slight. (May involve subtracting code rather than adding it).
Cost to Users:
None.
Cost of Non-Adoption:
The variation in syntax makes them harder to learn.
Benefits:
Ease of learning.
Aesthetics:
Symmetry is more aesthetic than asymmetry, at least to some of us.
Discussion:
Pitman supports this proposal.
The issue about whether the atomic ``var'' should be allowed at all in the
variable lists for let & let* is a separate issue. (So is whether
it should mean that the var is initially bound to nil.) Since it is allowed,
this proposal merely says that the alternative syntax of an atom within a
list with no initial value, ``(var)'', should also be allowed.
∂09-Dec-88 1705 X3J13-mailer Issue: DECLARATION-SCOPE (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 17:05:11 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 17:00:53 PST
Date: 9 Dec 88 17:00 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: DECLARATION-SCOPE (Version 4)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-170053-1466@Xerox>
This issue has two proposals, NO-HOISTING and LIMITED-HOISTING.
!
Issue: DECLARATION-SCOPE
References: Declaration Syntax (CLtL, Section 9.1, pp. 153-157)
LAMBDA-Expressions (CLtL, Section 5.2.2, pp. 59-66)
Cleanup issue FLET-DECLARATIONS (accepted)
Cleanup issue DECLARE-TYPE-FREE (accepted)
Category: CHANGE/CLARIFICATION
Edit history: V1: Hornig@Symbolics.COM -- 5 January 1988
Version 2, Moon, 2-Feb-1988 (edits based on discussion)
Version 3, Moon, 18-Sep-88, for private discussion between JonL and Moon
Version 4, JonL, 15-Nov-88 add 2nd proposal; major rewrite.
Problem description:
The description of the scope of declarations made with DECLARE is
unclear (although unambiguous) and arguably a mistake. At issue is
whether the scope of some or all of the declarations at the head of
a special form includes code appearing in any non-body part of that
special form. CLtL p.155 attempts to address the issue by classifying
declarations into two classes -- "pervasive" and "non-pervasive" -- but
it does not succeed very well.
A particular question of interest is whether the initial value forms for
LET, LET*, FLET, LABELS, DO, PROG etc. are included. The rules of CLtL,
on some cases, are clear enough to see that a declaration inside the
special form is "hoisted" up and around the whole form, so as to include
all the "initial value" forms (and "stepper" forms and "result" forms for
those constructs that have them). This means that lexical argument
variable X in the following function is inaccessible inside the initial
value forms of the LET:
(defun bar (x y) ;[1] 1st instance of x
(let ((old-x x) ;[2] 2nd instance of x -- same as 1st instance?
(x y)) ;[3] 3rd instance
(declare (special x))
(list old-x x)))
The declaration intended for the binding of X[3] also alters the
scoping of the reference of X[2]; likely, this was not an intended
consequence. [This is a simplification of the example on CLtL p.155].
In this discussion, the term "body" will include any "stepper" or
"result" forms, such as might be found in a DO or DO-mumble-SYMBOLS
construct. The reasoning for this is that such forms are always
included in the scope of all name bindings (if any) being established
by the special form. They form an extended part of the "body".
Proposal (DECLARATION-SCOPE:NO-HOISTING)
Specify that the scope of a declaration located at the head of a special
form or lambda expression is as follows:
(1) it always includes the body forms [as well as any "stepper" or
"result" forms]
(2) it also includes the scope of the name binding, if any, to which
it applies [LET, LAMBDA, FLET, DO, etc. introduce "name bindings";
LOCALLY doesn't.];
This very straightforward prescription depends on one rather subtle
point, namely that the scope of name bindings is an already solved
question. Whether or not a particular declaration affects an initial
value form (such as for LET or LET*) depends _solely_ on whether it is
applied to a variable or function (name) being bound whose scope
includes such forms. In this sense, the above specification limits the
scope of declarations for name bindings to be exactly the scope of the
name binding itself -- i.e. "like variable". Thus there would be no
"hoisting" of the special declarations in the example cited in the
problem description. [See the Discussion section for a review of the
CL rules on variable/function-name scoping in special forms.]
Those declarations not correlated with any name binding do not cover any
of the initial-value forms; their scope simply includes the body (as well
as any "stepper" or "result" forms). In a sense, the above specification
limits the scope of these kinds of declarations to be the same as an
arbitrary name binding in a LET or FLET construct -- i.e. "like variable".
[See also the issue DECLARE-TYPE-FREE.]
Thus there is to be no "hoisting" for declarations in special forms or
lambda expressions; the only initial value forms affected by a declaration
will be those included indirectly, by the effect, if any, that a
declaration has on a name binding.
A question may arise as to what it means for a declaration to "apply to",
or "be correlated to" a name binding. As stated above about variable
scoping, this is an already solved question in Common Lisp; it is not
the purpose of this proposal to alter, clarify or in any other way bear
upon the basic _applicability_ rules of declarations in Common Lisp.
However, a few reminders about these rules will help one understand the
above specification:
-- SPECIAL and TYPE declarations never apply to function bindings;
-- INLINE and FTYPE declarations never apply to variable bindings;
-- OPTIMIZE never applies to either kind of binding;
-- (<declaration> X) never applies to a binding of Y.
The specific rules are for the most part distributed throughout the
individual declaration definitions. The name-applicibility issue for
bindings must be specified independently of how the declaration scoping
issue is decided, and should not be confused with that scoping issue.
Proposal (DECLARATION-SCOPE:LIMITED-HOISTING)
Specify that the scope of a declaration located at the head of a special
form or lambda expression is as follows:
(1) it always includes the body forms [as well as any "stepper" or
"result" forms]
(2) if the declaration is applicable to a name binding in that form,
then it is limited to exactly the scope of that name binding [LET,
LAMBDA, FLET, etc. introduce "name bindings"; LOCALLY doesn't.];
(3) if the declaration is not applicable to a name binding in that form,
then it includes all the initial value forms, in addition to the
body forms.
This very straightforward prescription depends on one rather subtle
point, namely that the scope of name bindings is an already solved
question. This applies not only to LET and LET* variables, but to the
&optional, &key and &aux variables of LAMBDA-Expressions. In this sense,
the above specification limits the scope of declarations for name bindings
to be exactly the scope of the name binding itself. Thus there would be
no "hoisting" of the special declarations in the example cited in the
problem description.
Those declarations not correlated with any name binding act as if they
were included in a new LOCALLY construct wrapped around the entire
special form. Thus they are not scoped like an arbitrary variable
(or, "name binding") in that special form, but rather are "hoisted" up.
Whether or not a declaration is "hoisted" up around the special form in
which it occurs depends on whether or not it is "captured en passant" by
a correlated name binding.
A question may arise as to what it means for a declaration to "apply to",
or "be correlated to" a name binding. As stated above about variable
scoping, this is an already solved question in Common Lisp; it is not
the purpose of this proposal to alter, clarify or in any other way bear
upon the basic _applicability_ rules of declarations in Common Lisp.
However, a few reminders about these rules will help one understand the
above specification:
-- SPECIAL and TYPE declarations never apply to function bindings;
-- INLINE and FTYPE declarations never apply to variable bindings;
-- OPTIMIZE never applies to either kind of binding;
-- (<declaration> X) never applies to a binding of Y.
The specific rules are for the most part distributed throughout the
individual declaration definitions. The name-applicibility issue for
bindings must be specified independently of how the declaration scoping
issue is decided, and should not be confused with that scoping issue.
Examples:
;;; The following example is from a common-lisp mailing list discussion
;;; (from code suggested by Pavel Curtis). The question is whether or
;;; not the special declaration in FOO applies to the (1+ x) form.
(setf (symbol-value 'x) 6)
(defun foo (x) ;a lexical binding of X
(print x)
(let ((x (1+ x))) ;is the second X special or not?
(declare (special x)) ;`normal' declaration
(bar))
(1+ x))
(defun bar () (print (locally (declare (special x)) x)))
(foo 10) will printout of 10 and 11 by either proposal herein
(foo 10) will printout of 10 and 7 by CLtL style "hoisting"
;;; The following example is due to Jim Boyce, of Lucid Inc. It shows how
;;; the "hoisting" of the declaration inadvertently causes it to act more
;;; like a proclamation than a declaration; namely, the declaration is
;;; applied to two different variables (which happen to have the same
;;; name) -- the first variable is the lexical one bound on line [1] and
;;; the second variables is bound on line [3]. Whereas lexical scoping
;;; rules would say that the reference in line [2] is to the variable
;;; bound on line [1], the effect of the "hoisted" declaration is to
;;; make the line [1]'s variable inaccessible in the initial value forms.
(setf (symbol-value 'x) 6)
(defun bar (x y) ;[1] 1st instance of x
(let ((old-x x) ;[2] 2nd instance of x -- same as 1st instance?
(x y)) ;[3] 3rd instance
(declare (special x))
(list old-x x)))
(bar 'first 'second) ==> (first second) ;by either proposal herein
(bar 'first 'second) ==> (6 second) ;by "hoisting", a la CLtL.
Rationale:
These semantics are simpler to understand. Almost everyone feels that
the example of CLtL p.155 is very unnatural. LIMITED-HOISTING is less
of a change to CLtL semantics; but NO-HOISTING seems more natural to
most people since it restores a closer equivalence between LET forms
and LAMBDA-expressions. Also, several vendors report that customers
frequently seem to assume the semantics of NO-HOISTING.
Current practice:
Most implementations implement the rules in CLtL, as exemplified by
the example on p.155. Symbolics currently implements rules based on
Zetalisp which are different from both this proposal and Common Lisp.
Symbolics plans to change to Common Lisp rules in the future.
Cost to Implementors:
Modest; some minor fixes will be necessary to to compilers, interpreters
and "code walkers" that parse declarations.
Cost to Users:
Modest. It is mostly moot since users tend to avoid the "hoisting"
situations on special declarations.
It is possible to mechanically examine a program to determine whether
its behavior would change under the new rules. This permits an
implementation to provide a transition tool to ease conversion to the
new definition.
Cost of non-adoption:
Serious non-portability of code, since not every implementor seems to
agree on how to read the disputed rules of CLtL pp. 153-157; continuing
confusion in the user community.
Performance impact:
None.
Benefits:
Elimination of confusion; increase of portability between implementations.
Esthetics:
Simplifies the scoping issue; eliminates special-case scoping rules for
SPECIAL declarations.
Discussion:
Only the SPECIAL declaration has semantic import for CL; both
proposals specify an incompatible change for this case, to "retract"
the expansive scope stated or implied in CLtL. All other declarations
are considered "advice" to an optimizing compiler, and should have
no semantic effect on correct programs. However, programmers making
use of such declarations may notice a larger difference in the
NO-HOISTING proposal, since some of their INLINE, OPTIMIZE, TYPE,
etc. declarations will no longer apply to the initial-value forms.
One idiom which will be adversely affected by both of these proposals is:
(let ((*a* *a*))
;; rebind *a* to it's "old" value
(declare (special *a*))
...)
where *a* has not been proclaimed special. This idiom would likely
have to be written as:
(let ((*a* (locally (declare (special *a*)) *a*)))
;; rebind *a* to it's "old" value
(declare (special *a*))
...)
or [preferably!] *a* should be proclaimed special. Similar idiots
like this may be in use for LAMBDA-Expressions, or DEFUNs etc.
On the other hand, the inadvertent "shadowing" which prevents the
following LET's initial value forms from referencing the input argument
is handily solved by either proposal herein. If neither of these
proposals is not adopted, then the intent of the code for BAR:
(defun bar (x y) ;[1] 1st instance of x
(let ((old-x x) ;[2] 2nd instance of x -- same as 1st instance?
(x y)) ;[3] 3rd instance
(declare (special x))
(list old-x x)))
would likely have to be expressed by introducing new LET contours:
(defun bar (x y) ;[1] 1st instance of x
(let ((old-x x)) ;[2] 2nd instance of x -- same as 1st instance?
(let ((x y)) ;[3] 3rd instance
(declare (special x))
(list old-x x))))
The source of additional confusion has long been that TYPE declarations
had to be treated differently from all other declarations; this was because
of the prohibition found on p158 of CLtL. Given the acceptance of the
DECLARE-TYPE-FREE proposal, it no longer is necessary to make an exception
for it, nor to categorize declarations into "pervasive" and "non-pervasive",
or "free" and "bound".
It is not the purpose of this proposal to alter, clarify or in any
other way bear upon the scoping rules of variables in Common Lisp.
However, a few reminders about these rules will help one understand
the above prescription. Except LET*, PROG*, DO*, LABELS, and MACROLET,
all the other special forms of CLtL p154 which admit declarations have
the property that the scope of the name binding does not include any
initial value form. As a review of these scopes, note:
-- for LET, FLET, MULTIPLE-VALUE-BIND, none of the initial value
forms are included in the variables' (or functions') scope;
-- for DO-<mumble>-SYMBOLS, the initial value forms are not included,
but the optional result forms are included;
-- for DO, DOLIST, and DOTIMES, the initial value forms are not
included, but the stepper forms and the optional result forms
are included;
-- for LET*, PROG*, and DO*, a variable's scope also includes the
remaining initial value forms, for subsequent variable bindings;
-- for LABELS and MACROLET, a function name's scope includes all the
code forms for the functions being defined by the special form
[a compiler writer must know how not to get into an infinite loop
of substitutions when there are 'in-line' declarations on these
mutually recursive names];
-- for a LAMBDA application, none of the explicit value forms are
included in the bound variable scoping; however, the 'initform'
code (if any) for &optional, &key, and &aux bindings are included
in the same way as LET* does;
-- for DEFUN, DEFMACRO, DEFTYPE and DEFSETF follow the rules for
LAMBDA-Expressions (CLtL, Section 5.2.2, pp. 59-66).
Remember also that new name bindings "shadow" (after a fashion) any
higher level binding or declarations. E.g., presuming that no
proclamations are in effect, consider the inner let bindings of:
(locally (declare (special x) (float y))
(let ((x 5) (y 10))
(print (+ x y))))
then x is bound as local (not special); and y is bound with no particular
type information [because the 'y' being bound is a different variable
than the 'y' declared float in the outer scope].
It has been suggested that compilers could be a bit more helpful in
detecting anomalous bindings, such as in the LET* following:
(defun bar (x y)
(let* ((old-x x)
(x y)
(new-x x))
(declare (special x))
(list old-x x new-x)))
The collection of variables named X in the LET* binding and initial
forms includes both local (lexical) and special ones.
∂09-Dec-88 1742 X3J13-mailer Issue: DECLARE-TYPE-FREE (Version 8)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 17:41:49 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 17:35:03 PST
Date: 9 Dec 88 17:34 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: DECLARE-TYPE-FREE (Version 8)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-173503-1691@Xerox>
This is one of several variations discussed.
!
Forum: Cleanup
Issue: DECLARE-TYPE-FREE
References: CLtL p.158
DECLARATION-SCOPE
Related issues: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
DECLARATION-SCOPE
Category: CLARIFICATION/ADDITION
Edit history: Version 1, 18-Sep-88, Moon
Version 2, 22-Sep-88, Moon
(small edits to reflect mail discussion)
Version 3, 22-Sep-88, Masinter
Version 4, 27-Sep-88, JonL
Version 5, 30-Sep-88, Masinter (cost to implementors)
Version 6, 06-Oct-88, Pitman (minor edits in Discussion)
Version 7, 5-Dec-88, Masinter (scope->extent)
Version 8, 7-Dec-88, Masinter (back to scope)
Problem description:
Section 9.2 of CLtL, p158, says that a declaration specifier like
(TYPE type var1 var2 ...) "... affects only variable bindings".
Since declarations can occur in contexts other than establishing
"variable bindings", most people interpret this statement to mean
that type declarations not in such context are either (1) completely
to be ignored, or (2) invalid CL syntax. Thus both of the following
forms would be suspect in that the type declarations could not have
any effect:
(if (and (typep x 'fixnum) (typep y 'fixnum))
(locally (declare (fixnum x y)) ;LOCALLY does not bind
...algorithm using x and y...) ; any variables.
...similar algorithm using x and y...)
(let ((y 'foo))
(setq y 10)
(let ((x 5)) ;'y' is not being bound in
(declare (fixnum y)) ; this particular context.
(incf y)
...random algorithm...))
Proposal (DECLARE-TYPE-FREE:ALLOW):
Specify that a type declaration does not only "affect variable bindings";
rather, type declarations are legal in all declarations. The interpretation
of a type declaration is that, during the execution of any expression
within the scope of the declaration, it is an error for the value of
the declared variable not to be of the declared type. For declarations
that are associated with variable bindings, the type declaration also
applies to the initial binding of the variable. In the special case
of a declaration for which there are no executable expressions
within the scope of the declaration (e.g., (locally (declare (integer x)))),
the result is as if there were executable expressions.
Examples:
;; this is an error:
;; the assertion that x is a fixnum is violated between the two
;; calls to (zap)
(let ((x 12) (y 'foo))
(flet ((zap () (rotatef x y)))
(locally (declare (fixnum x))
(zap)
(zap)
x)))
;; this is an error, because the assertion that x is a fixnum
;; is violated during the call to zap, even though few
;; implementations will be able to check:
(let ((x 12) (y 'foo))
(flet ((zap ()
(rotatef x y)
(rotatef x y)))
(locally (declare (fixnum x))
(zap)
x)))
;; this is an error, even though the violation of the type
;; constraint happens after the form with the declaration
;; is exited.
(let ((f (let ((x 3)) (declare (fixnum x)) #'(lambda (z) (incf x z)))))
(funcall f 4.3))
Rationale:
This proposal enables optimizing compilers to make use of the otherwise
ignored type information. Many people have often asked for it, and
there is no strong reason to forbid it.
Current practice:
Lucid Common Lisp allows "free" type declarations; under some
circumstances the compiler issues a warning message that such usage
is an extension to Common Lisp.
Cost to Implementors:
Implementations that might currently warn about such declarations
would have to remove the warning; otherwise, it is valid to ignore
type declarations.
Cost to Users:
None, this is a compatible addition.
Cost of non-adoption:
Common Lisp will be less self-consistent.
Benefits:
Programmers will be able to use type declaration to express their
intent, rather than having to manually insert THE wrappers around
every reference.
Esthetics:
It is a simpler interpretation for type declaration specifiers, with
fewer special cases; hence reduces the number of exceptions in the
language.
Discussion:
Another cleanup issue, DECLARATION-SCOPE, addresses the scope of
declarations. This proposal carefully uses the phrase "within the
scope of the declaration" to avoid confounding the two issues.
This issue has been discussed at the Fort Collins X3J13 meeting in
November 1987, and at length on the various electronic mailing lists.
At least one current implementation is able to generate more efficient
code when declarations are associated with a particular binding, since
it then has the option to choose type-specific specialized storage for
the runtime value of the variable. So, for example,
(let ((x v)) (declare (type float x)) (+ x x))
is sometimes more efficient than
(let ((x v)) (locally (declare (type float x)) (+ x x)))
However, the local type declarations allowed by this proposal do
provide some useful information, even if it is not the *most* useful.
It is possible for a sufficiently "smart" compiler to infer the
equivalent of a "binding declaration" when it can ascertain that the
type of the binding value -- 'v' above -- is commensurate with the
type locally declared over the scope of usage of the variable.
It may be useful for a compiler to issue a warning whenever it finds
nested type declarations referring to the same variable and the
intersection of the declared types is null.
Documentation might want to discuss the style implications of
nested declarations intersecting. The interesting cases are:
- An inner declaration could be a subtype of an outer one.
This is the most useful case and probably the only one to
be encouraged in code written by humans. e.g.,
(locally (declare (type number x))
(locally (declare (type integer x))
...use X as integer...))
- An outer declaration could be a subtype of an inner one.
This is useless but harmless. It might happen as the result
of certain macro situations. e.g.,
(locally (declare (type integer x))
(locally (declare (type number x))
...use X as integer...))
- Two types may only partially overlap. This would presumably
happen only as the result of a macro expansion.
(locally (declare (type fixnum x))
(locally (declare (type (or bit package) x))
...use X as BIT...))
∂10-Dec-88 0348 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED (Version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Dec 88 03:48:01 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03444g; Sat, 10 Dec 88 03:45:20 PST
Received: by bhopal id AA00267g; Sat, 10 Dec 88 03:47:17 PST
Date: Sat, 10 Dec 88 03:47:17 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812101147.AA00267@bhopal>
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu, masinter.pa@Xerox.COM
In-Reply-To: cl-cleanup@sail.stanford.edu's message of 9 Dec 88 15:58 PST <881209-155854-1325@Xerox>
Subject: Issue: TYPE-OF-UNDERCONSTRAINED (Version 2)
I believe this issue was incorrectly mailed to X3J13. By "cleanup" rules,
only those issues that have "settled down in sub-committee" are to be
mailed out now, and this issue has been under daily disucssion for the
past week. Furthermore, this version 2 has had no review whatsoever;
worse yet, it appears to have an egregious bug in it (a logical inversion
in one sentence).
-- JonL --
∂10-Dec-88 0513 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 8)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Dec 88 05:13:53 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03592g; Sat, 10 Dec 88 05:11:16 PST
Received: by bhopal id AA00374g; Sat, 10 Dec 88 05:13:13 PST
Date: Sat, 10 Dec 88 05:13:13 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812101313.AA00374@bhopal>
To: masinter.pa@Xerox.COM
Cc: x3j13@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: cl-cleanup@sail.stanford.edu's message of 9 Dec 88 17:34 PST <881209-173503-1691@Xerox>
Subject: Issue: DECLARE-TYPE-FREE (Version 8)
Please retract this Issue from X3j13 now. You (Larry) substantially
reworked it during the past few days, and provided no opportunity for
review by the principals who originated the proposal.
In particular, if I read Kent's commentary right, from the msg:
Date: Wed, 19 Oct 88 15:42 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-TYPE-FREE (Version 6)
then his intent, along with that of Moon and myself (who also worked
on this proposal), is diametrically opposite of what you now have it
to be.
In particular, your explanation:
;; this is an error:
;; the assertion that x is a fixnum is violated between the two
;; calls to (zap)
(let ((x 12) (y 'foo))
(flet ((zap () (rotatef x y)))
(locally (declare (fixnum x))
(zap)
(zap)
x)))
was explained as exactly the opposite by Kent on 19-Oct-88; and the rest
of us have always agreed that "free" type declarations need not be
consistent with "specialized storage" -- that they are merely equivalent
to wrapping (THE <type> ...) around lexical occurances of the variable.
It this point is debateable, it should have been debated in subcommittee
before "release" of the issue.
-- JonL --
∂10-Dec-88 1236 X3J13-mailer ISO Meeting Status
To: ROSENKING@a.ISI.EDU
CC: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
As I mentioned in my trip report, the January ISO meeting which was to
have been held immediately following the X3J13 meeting has been cancelled.
There is no possibility to revive it now. Also as I mentioned, I believe
that the meeting was hastily cancelled - had I been chairman of the
committee I would not have suggested the cancellation and I would not have
entertained the motion to cancel unless there was an overwheling sense of
the committee that it should be cancelled, regardless of any personal
circumstances such as lack of travel funds.
All of the US ISO representatives will, I believe, be at the January X3J13
meeting, and it is reasonable to have a discussion about the ISO situation
at that meeting. However, this meeting is our most important technical
decision-making meeting. I suggest that people who have opinions about the
ISO situation should try to send mail beforehand or try to formulate a
concise statement so that the normal business of the next meeting can be
conducted as planned.
-rpg-
∂10-Dec-88 1528 LOGMTC-mailer Seminar
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Dec 88 15:28:19 PST
Received: by csli.Stanford.EDU (4.0/4.7); Sat, 10 Dec 88 15:27:05 PST
Date: Sat 10 Dec 88 15:27:04-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: Seminar
To: logic@csli.Stanford.EDU
Message-Id: <597799624.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Seminar in Logic and Foundations
Speaker: Paolo Mancosu
Title: "Generalizing classical and effective analogues for model theory"
(cont'd.)
Time: Monday, Dec. 12, 4:15-5:30 PM
Place: Room 381-T, Math Bldg, Stanford
This is the last seminar of the quarter.
S. Feferman
-------
∂11-Dec-88 0007 hoffman@csli.Stanford.EDU the Symbolic Systems Forum Tentative Winter Schedule
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Dec 88 00:07:30 PST
Received: by csli.Stanford.EDU (4.0/4.7); Sun, 11 Dec 88 00:00:44 PST
Date: Sun 11 Dec 88 00:00:39-PST
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: the Symbolic Systems Forum Tentative Winter Schedule
To: MerryChristmas@CSLI.Stanford.EDU
Message-Id: <597830439.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Here is a tentative scheduling for the Symbolic Systems Forum
Winter Quarter. The schedule is somewhat tentative (although
Rosenschein, Feldman, Feferman, and Shrager are all
confirmed, the scheduling on some others has not been quite
resolved yet.) Thanks much and merry christmas!
Symbolic Systems Forum Scheduling:
Winter Quarter 89:
Jan 20th, Professor Stan Rosenschein:
on the prospects of and in Artificial Intelligence
Jan 27th, Professor Jerry Feldman (UCB):
on The Different Kinds of Connectionism
Feb 3rd, either Professor Sells on something linguistic
or Dr. Nissenbaum on Computers and Ethics
Feb 10th, Professor David Wellbury (German Studies):
Semiotics
Feb 17th, Dr. Bernardo Huberman (Xerox PARC, Physics):
on the Ecology of Computation
Feb 24th, Professor Solomon Feferman:
Turing`s Oracle
March 3rd, Dr. Jeff Shrager (Xerox PARC):
undetermined
March 10th, Dr. Ruben Kleiman (Apple):
Ontology and Computer Science
-------
∂11-Dec-88 1211 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu under-represented groups
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Dec 88 12:11:10 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sun 11 Dec 88 12:08:59-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA11393; Sun, 11 Dec 88 12:07:59 PDT
Date: Sun, 11 Dec 88 12:07:59 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8812112007.AA11393@Tenaya.stanford.edu>
To: faculty@score
Cc: gibbons@sierra
Subject: under-represented groups
I want to keep you, the faculty, senior staff, and student
representatives, up to date on various efforts that I engage in from
time to time regarding what we at Stanford can do to encourage more
graduate students from under-represented groups to specialize in
computer science. Here, for your information, are some notes from a
recent lunch meeting which I organized:
------
Notes Taken During October 20, 1988 Lunch Discussion with Black Students
Nils Nilsson
November 21, 1988
I hosted a lunch on October 20, 1988 to talk about ways to increase
the number of black students in computer science. Attending the lunch
were:
Eric Freeman, President, SBSE (Society of Black Scientists and Engineers),
325-9554
Chris Gourrier, student, member SBSE
Cheryl Hawthorne, Associate Dean, Minority Affairs, SOE, 723-9107
Leonard Wesley, SRI, wesley@iu.ai.sri.com
Joe Oliger, Computer Science Dept., oliger@pride
Hugh McGuire, CS Ph.D. student, mcguire@polya
Derrick Burns, CS Ph.D. student, burns@polya
James Jones, MSCS student, jjones@polya
John Kenney, MSCS student, jjk@portia
Sobani Warner, student, 329-1923
Rhonda Andrew, student, 322-6945
The meeting was prompted by a discussion I had with Dr. Leonard Wesley
of SRI International who is concerned about statistics showing a
recent decline in the number of PhDs in computer science earned by
black students. Len had attended a symposium sponsored by the Space
Science and Technology Institute in Washington, D.C. to consider
these problems. Len thought there were several things that Stanford
and SRI could do to help. For example, NSF is sponsoring a workshop
in Atlanta for minority colleges to focus on how minority students can
be kept in science. Perhaps Stanford/SRI could co-host a regional
symposium on problems of minority participation.
Several people attending the lunch spoke about what they thought could
be done. Eric Freeman stressed the need for supporting the existing
programs and organizations---such as MESA. Derrick Burns mentioned the
importance of working with the Black Scientists and Engineers group at
Stanford. After ensuing discussion, it was recommended that a meeting
be held to describe Stanford's CS Masters and PhD programs to
prospective students.
John Kenney recommended that the CS Department take more steps to
welcome black students and introduce them to the community. He said
that it took some time after his arrival at Stanford to get to meet
and know fellow black students. There was discussion about the great
importance of having role models---both among the faculty and among
older students.
Hugh McGuire thought we should give advice to new students about whom
they might contact when they arrive at Stanford. He also stressed the
importance of all of us speaking out when injustices occur. Hugh
seconded the idea of having a meeting to talk to undergraduates about
the CS graduate programs.
Cheryl Hawthorne wondered whether or not we could give TA credit to
people who assisted with summer workshops or MESA presentations.
After the meeting Cheryl provided me with the following notes
describing some concrete proposals:
At the college level:
1. The ideal of faculty visiting minority student organizations'
weekly meetings offers a chance for the faculty and staff to interact
socially. Student comfort levels may increase due to informal contact
and a chance for members of each group to interact as equals outside
of the classroom (lecture hall or office).
2. Offer research credit to students for developing curriculum to
introduce basic computer science concepts to pre-college students (use
SRI as a resource of personnel).
3. Provide credit to TA's to run special workshop/seminars for
minority undergraduates and masters students. This also provides
lecture experience for Ph.D. students.
4. Form Graduate Welcoming Committee. Department notifies committee
of newly accepted minority students.
At the pre-college level:
1. Establish Computer Science Institute for pre-college teachers that
will provide them with curriculum and tools to develop activities to
teach computer science in the classroom. Ph.D. students receive
credit for teaching.
2. Establish Computer Science Institute for pre-college students to
teach basic programming skills, languages, and literacy. Graduate and
undergraduate students receive credit for teaching in the Institute.
3. Provide speakers for pre-college students.
The discussion about improving the situation of blacks in computer
science was very positive, and I think a number of good suggestions
were made. The purpose of my writing up these notes is to stimulate
the process of us taking the next steps to DO something in addition to
talking about issues.
---Nils Nilsson
∂12-Dec-88 0832 X3J13-mailer Re: ISO Meeting Status
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 08:32:52 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA08427; Mon, 12 Dec 88 08:35:20 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA08700; Mon, 12 Dec 88 08:32:00 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA05945; Mon, 12 Dec 88 08:32:35 PST
Message-Id: <8812121632.AA05945@suntana.sun.com>
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Cc: ROSENKING@a.ISI.EDU, x3j13@SAIL.Stanford.EDU
Subject: Re: ISO Meeting Status
In-Reply-To: Your message of 10 Dec 88 12:36:00 -0800.
<14Oq5E@SAIL.Stanford.EDU>
Date: Mon, 12 Dec 88 08:32:33 PST
From: kempf@Sun.COM
>All of the US ISO representatives will, I believe, be at the January X3J13
>meeting, and it is reasonable to have a discussion about the ISO situation
>at that meeting. However, this meeting is our most important technical
Considering the recent exchange of notes on the ISO Meeting, I think it would be
worthwhile to have this discussion. I also agree that it should be
arranged such that it does not conflict with the technical sessions,
as they are, at this point, more important. Perhaps we can schedule an
evening session for it.
jak
∂12-Dec-88 0942 X3J13-mailer Issue release & scheduling
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 09:42:06 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 09:31:01 PST
Date: 12 Dec 88 09:30 PST
From: masinter.pa@Xerox.COM
Subject: Issue release & scheduling
To: x3j13@sail.stanford.edu
Message-ID: <881212-093101-4200@Xerox>
I will be mailing out hardcopy of the "released" issues this week. If
there are errors, problems, or corrections to any of the issues--
especially the late-breaking ones-- please prepare amendments or new
versions to bring to the January meeting. While there will be a ballot, the
purpose of the ballot is to help us avoid discussing the non-controversial
issues; the ballot will tell us which issues should be included in a
"block" vote of endorsement/rejection. Certainly there will be opportunity
at the January meeting to correct mistakes or review issues, if there is
some belief that they were incorrectly framed, misunderstood, or should
otherwise be reviewed.
My personal schedule for getting the mailing out is tight enough that it is
likely there will be more of these than just the ones that JonL has pointed
out. Given the large number of issues, there's been more haste than usual,
for which I apologize.
After issues go into the mail, I will be on vacation until the new year, so
please do not expect a reply if you send mail to me alone.
∂12-Dec-88 0942 X3J13-mailer Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 09:42:14 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 09:34:46 PST
Date: 12 Dec 88 09:34 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE (Version 3)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-093446-4207@Xerox>
!
Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
References: CLtL p. 312-314
Category: CLARIFICATION
Edit History: V1, 5 Aug 1988, Sandra Loosemore
V2, 15 Sep 1988, Sandra Loosemore
V3, 7 Dec 1988, Masinter
Problem Description:
CLtL doesn't make clear whether defstructs that :INCLUDE another
structure type and do not specify a :PRINT-FUNCTION inherit the
:PRINT-FUNCTION of the parent structure type. While it is stated on
page 314 that #S syntax is used if a :PRINT-FUNCTION is not specified,
the language on page 313 indicates that all operations on the parent
type will also work on objects of the child type. Because of the
ambiguity, existing implementations have gone both ways, and users
cannot depend on either #S syntax or the parent type's :PRINT-FUNCTION
being used.
Proposal: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Clarify that defstruct types which :INCLUDE another type but do not
specify an explicit :PRINT-FUNCTION inherit the structure print
function from the :INCLUDE'd type. A print function that uses the
default #S syntax (overriding any print function for the parent type)
can be specified by providing the :PRINT-FUNCTION option without an
argument.
Supplying a :PRINT-FUNCTION in a DEFSTRUCT is equivalent
to defining an appropriate method on the PRINT-OBJECT generic
function.
Rationale:
Users typically specify a print function for a structure type because
its slots will contain circular objects or large internal data
structures which are confusing when printed. Any structure type that
:INCLUDEs this type will also contain the same slots; it seems more
reasonable to inherit the parent's print function than to use the
default #S syntax.
Current Practice:
Lucid Common Lisp makes structures inherit print functions.
VaxLisp uses #S syntax unless an explicit :PRINT-FUNCTION
is specified.
Cost to implementors:
The changes to non-conforming implementations should be fairly minor
and localized.
Cost to users:
It can't be any worse than the status quo.
Benefits:
An area of ambiguity in the language will be removed.
Discussion:
Pitman and VanRoggen support this proposal.
The original version of the proposal did not provide for a way to
force #S syntax to be used. This functionality was added to the
current version because there seemed to be general agreement that it
would be useful. Other alternatives would be to name the function
that does what the #S printer does, or to provide a function that
returns the #S information as a list (as suggested by Waters) so users
can write their own.
∂12-Dec-88 1004 X3J13-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 10:04:29 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 09:55:34 PST
Date: 12 Dec 88 09:53 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 4)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-095534-4250@Xerox>
!
Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
References: CLtL p.308 & 86-003 p.4
Category: CLARIFICATION
Edit history: Version 1 by Skona Brittain 05/13/88
Version 2 by Larry Masinter 14-Sep-88
Version 3 by Larry Masinter 23-Sep-88
Version 4 by Larry Masinter 31-Oct-88
Problem Description:
The case of two slots of a structure having the same name is not
discussed in CLtL. Is it allowed?
Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR):
It is an error for two slots in a structure type to have the same symbol-name;
that is, the SYMBOL-NAME of the slot names should not be STRING=.
This holds when they were both named directly by the same call to defstruct
or when one is present by virtue of being in an included structure.
The situation of expanding a DEFSTRUCT macro with a duplicate name "should
signal an error." (While not yet formally defined, the intent is that
the error signalling may occur when compiling a file that contains
duplicate names or when evaluating a DEFSTRUCT form with duplicate names
in an interpreter.)
Examples:
(defstruct struc slot slot) would be an error. So would
(defstruct (struc2 (:include struc1)) slot) if preceded by
(defstruct struc1 slot).
Rationale:
Since it would be difficult to prescribe reasonable behavior for
this situation, it should be considered an error.
Current Practice:
In KCL, if two slots have the same name, no warning message is
given but mysterious behavior ensues. (Their default values are
both whatever is given for the second one, neither can be given a
different value via a call to the constructor function, only the
second one's value can be changed by setf...)
Cost to Implementors:
None.
Cost to Users:
None.
Cost of Non-Adoption:
Possible confusion.
Benefits:
Clarity.
Aethetics:
Something that is not well-defined and leads to erratic behavior
should be explicitly considered an error.
Discussion:
Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.
This issue was first circulated to X3J13 June 1988.
This proposal does not address the issue of whether NIL is a legitimate
slot name. There seems to be no current reason why it might be prohibitied.
The compiler committee is proposing to address generally the issue
of how macro-expansion errors during compile-file might be caught and
turned into compiler warnings.
∂12-Dec-88 1016 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Faculty Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Dec 88 10:16:32 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 12 Dec 88 10:12:27-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA06184; Mon, 12 Dec 88 10:13:16 PDT
Date: Mon, 12 Dec 1988 10:12:54 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score
Subject: Faculty Lunch
Message-Id: <CMM.0.87.597953574.chandler@polya.stanford.edu>
Tomorrow's faculty lunch will be the last one of the Autumn Quarter. There
will be no guest speaker....no particular topic to discuss. Just come and
"socialize" and ENJOY!!!!!
∂12-Dec-88 1054 X3J13-mailer Issue: EXIT-EXTENT (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 10:53:55 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 10:39:04 PST
Date: 12 Dec 88 10:37 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: EXIT-EXTENT (Version 5)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-103904-4431@Xerox>
!
Issue: EXIT-EXTENT
References: CATCH, THROW,
BLOCK, RETURN, RETURN-FROM,
TAGBODY, GO, UNWIND-PROTECT,
Dynamic extent (CLtL p.37),
Nested dynamic extents (CLtL p.38),
Blocks can only be exited once (CLtL p.120),
Catch is disestablished just before the values
are returned (CLtL p.139).
Related issues: UNWIND-PROTECT-NON-LOCAL-EXIT is superseded
by this one.
Category: CLARIFICATION
Edit history: ... Version 5 of UNWIND-PROTECT-NON-LOCAL-EXIT, 23-May-88 ...
Version 1, 5-Sep-88, by Moon, for discussion
Version 2, 1-Oct-88, by Masinter, minor edits
Version 3, 7-Oct-88, by Moon, wording improvements
Version 4, 7-Dec-88, by Masinter, add MEDIUM from
UNWIND-PROTECT-NON-LOCAL-EXIT, discussion.
Version 5, 12-Dec-88, Masinter, clarify MINIMAL allows MEDIUM
Problem description:
CLtL does not specify precisely when the dynamic extent (lifetime)
of a nonlocal exit such as a CATCH, BLOCK, or TAGBODY ends.
For example, at what point is it no longer possible to RETURN-FROM
a particular BLOCK?
(Terminology: In this issue writeup, the noun "exit" is
refera to the thing that can be exited from, rather than the
act of exiting. When the extent of an exit has ended, it is
no longer legal to exit from it. This is different from
the scope of the exit. For example, a BLOCK has lexical
scope but dynamic extent; a the scope of a CATCH--the
visibility of the CATCH tag to corresponding THROWs--
could differ from the extent of the CATCH.)
The problem arises when there are nonlocal exits from the
"cleanup" clauses of an UNWIND-PROTECT.
There are three cases of interest:
(1) Normal exit from a CATCH, BLOCK, or TAGBODY, or equivalent such as
PROG. A normal exit occurs when the last form in the body of one of
these constructs completes its evaluation without performing a transfer
of control.
(2) Nonlocal exit from the target of a THROW or RETURN. A nonlocal exit
occurs when control is transferred by THROW, RETURN, or RETURN-FROM.
The CATCH or BLOCK named in the THROW, RETURN, or RETURN-FROM is
referred to as the target. The TAGBODY containing the tag named by a
GO is also referred to as the target, but GO differs from the other
nonlocal control transfer operators because GO does not exit its target.
For example,
(3) Abandonment of an exit passed over by THROW, RETURN, or GO. A
CATCH, BLOCK, or TAGBODY that is dynamically nested inside the target of
a nonlocal transfer of control is said to be passed over when control is
transferred to the target. The target itself is not said to be passed
over.
For example, in
(block testem
(when (zilched) (return-from testem nil))
(when (zorked) (throw 'uh-oh))
(format t "Neither zilched nor zorked."))
if (zilched) returns true, the block testem is exited via a
'nonlocal exit'. If (zorked) returns true, the block testem
is 'passed over'. Otherwise, the block is exited normally.
The terms "normal exit", "target", and "passed over" will be used with
these meanings for the remainder of the discussion.
CLtL is unambiguous about case 1. In case 2, the extent could end
anywhere from the time the THROW or RETURN commences, until the time the
transfer of control is completed. In case 3, the extent could end
anywhere from the time the THROW, RETURN, or GO commences, until the
time the transfer of control is completed. In case 2, it is clear that
the extent of the target ends before the transfer of control completes,
since a block cannot be exited twice, but it is not made clear whether
the extent ends before or after execution of UNWIND-PROTECT cleanup
forms. CLtL says nothing about case 3, although a note on p.38 implies
that the extent of a passed-over exit should end no later than the end
of the extent of the target exit. It would make sense for the extent
of an exit passed-over by GO to end no later than when the transfer of
control is completed, but CLtL says nothing about this.
!
Proposal (EXIT-EXTENT:MINIMAL):
The dynamic extent of an exit, whether target or passed-over, ends as
soon as the THROW, RETURN, or GO commences. In the language of the
implementation note on p.142, the extent ends at the beginning of the
second pass. It is an error for an UNWIND-PROTECT cleanup form executed
during a nonlocal transfer of control to attempt to use an exit whose
dynamic extent ended when the nonlocal transfer of control commenced.
Note that this does not affect the extent of the binding of CATCH
tags; that is, under this proposal, a THROW to a CATCH which was
already in the process of being exited would be an error.
This proposal is called "minimal" because it gives exits the smallest
extent consistent with CLtL. A program that presumed a longer extent
would be in error. Implementations may support longer extents for
exits than is required by this proposal; in particular, an
implementation which allowed the larger extent of the MEDIUM
proposal below would still conform.
Proposal (EXIT-EXTENT:MEDIUM):
The dynamic extent of an exit, whether target or passed-over, ends
only after the exit is complete.
A transfer of control from within an UNWIND-PROTECT cleanup form
to a point outside of the UNWIND-PROTECT causes the original control
transfer which initiated the execution of the cleanup forms to be
abandonded.
During the execution of the cleanup forms of an UNWIND-PROTECT a
non-local exit to a point outside of the scope of the UNWIND-PROTECT,
but still within the dynamic scope of of the target of the original
non-local exit succeeds, and the original pending exit is discarded.
Where an UNWIND-PROTECT cleanup form attempts a non-local exit to a
point outside the original non-local exit, control is passed to the
outer exit (and the pending original non-local exit is discarded.)
In no case will UNWIND-PROTECT cleanup forms ever be attempted more
than once.
!
Examples:
Each of the following programs are an error under either
proposal:
;; Error: BLOCK has normal exit before RETURN
(funcall (block nil #'(lambda () (return))))
;; Error: normal exit before GO
(let ((a nil))
(tagbody t (setq a #'(lambda () (go t))))
(funcall a))
;; Error: TAGBODY is passed over, before GO
(funcall (block nil
(tagbody a (return #'(lambda () (go a))))))
Each of these programs are an error under MINIMAL, but
not under MEDIUM:
;;returns 2 under MEDIUM, is error under MINIMAL
(block nil
(unwind-protect (return 1)
(return 2)))
;;returns 2 under MEDIUM, is error under MINIMAL
(block a
(block b
(unwind-protect (return-from a 1)
(return-from b 2))))
;; returns 2 under MEDIUM, is error under MINIMAL
(catch nil
(unwind-protect (throw nil 1)
(throw nil 2)))
;; returns 2 under MEDIUM, is error under MINIMAL
(catch 'a
(catch 'b
(unwind-protect (throw 'a 1)
(throw 'b 2))))
;; An error under MINIMAL because the catch of b is passed over by
;; the first throw, hence portable programs must assume its dynamic extent
;; is terminated. The catch is not yet disestablished and therefore it
;; is the target of the second throw.
;; the following is an error under MINIMAL; the extent of the
;; inner catch terminates as soon as the throw commences, even
;; though it remains in scope. Thus, the throw of :second-throw
;; sees the inner catch, but its extent has ended.
;; under MEDIUM, it prints "The inner catch returns :second-throw"
;; and then returns :outer-catch.
(catch 'foo
(format t "The inner catch returns ~s.~%"
(catch 'foo
(unwind-protect (throw 'foo :first-throw)
(throw 'foo :second-throw))))
:outer-catch))
The following program is not an error. It returns 10. The inner
catch of a is passed over, but this is not case 3 because that catch
is disestablished before the throw to a is executed.
(catch 'a
(catch 'b
(unwind-protect (1+ (catch 'a (throw 'b 1)))
(throw 'a 10))))
The following cases are errors under MINIMAL, and have
the following interpretation under MEDIUM:
In
(CATCH 'FOO
(CATCH 'BAR
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
the pending exit to tag FOO is discarded by the second THROW
to BAR and the value 4 is transfered to (CATCH 'BAR ...),
which returns 4. The (CATCH 'FOO ...) then returns the 4
because its first argument has returned normally.
XXX is not printed.
In
(CATCH 'BAR
(CATCH 'FOO
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
the value 4 is returned from the (CATCH 'BAR ...); XXX is not printed.
. 3 evaluates to itself and is saved by THROW which begins
searching for tag FOO.
. 4 evaluates to iself and is saved by THROW which begins
searching for tag BAR.
. It is not an error, even though the
BAR tag is not found within the local dynamic scope of
the UNWIND-PROTECT cleanup form containing (THROW 'BAR 4)
but is found outside the scope of the target of the
pending THROW to FOO.
Rationale:
For MINIMAL: Giving exits the smallest extent consistent with CLtL
maximizes freedom for implementations; there are few applications,
if any, that require a longer extent.
For MEDIUM: Giving exits a longer exent has cleaner semantics.
Current practice:
Both implementations of Symbolics Genera (3600 and Ivory) end the extent
of a target block or catch at the moment the values are returned, and
end the extent of a passed-over exit at the moment the THROW, RETURN, or
GO commences. This choice of extent maximizes efficiency within the
particular stack structure used by these implementations, by avoiding
the need to retain the control information needed to use a passed over
exit through the transfer of control. Genera signals an error if an
attempt is made to use an exit that has been passed over.
In some implementations, the extent of a target exit lasts until the
exit has been completed; in those implementations, it is possible for a
throw or non-local exit to be effectively "stopped" by an UNWIND-PROTECT
cleanup clause that performs a nonlocal transfer of control to a
passed-over exit.
Some implementations crash or otherwise generate garbage code for
non-local exits from cleanup clauses of UNWIND-PROTECT.
Cost to Implementors:
No currently valid implementation will be made invalid by the MINIMAL
proposal. Some implementors may wish to add error checks if they
do not already have them.
MEDIUM would have a high cost for those implementations that currently
have shorter exent.
Cost to Users:
Most user programs don't do this, so there is likely little cost
of converting existing code in any case. In any case, current implementations
differ enough that this issue ostensibly does not
affect current portable programs. Some users might have code that
relies on the "unstoppable loops" that can be created with the MEDIUM
proposal.
Benefits:
Either proposal would make Common Lisp more precisely defined.
Cost of non-adoption :
The semantics of exits will remain ambiguous.
Esthetics:
Precisely specifying the meaning of dynamic extent improves the language.
Leaving implementations free to implement a longer extent if they choose
can be regarded as unesthetic, but consistent with Common Lisp philosophy.
Having a CATCH that is in scope even though its extent has ended may
seem unesthetic, but it is consistent with how BLOCK behaves.
Discussion:
This issue is controversial. It was first discussed under the issue
named UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT. The issue was recast as
the more global one of "extent of exits" rather than the specific
one of "what happens if a cleanup in an UNWIND-PROTECT does a non-
local exit", but the problem cases for both topics are the same.
The goal of the MINIMAL proposal is to clarify the ambiguity in CLtL while
minimizing changes to the current situation. The MEDIUM proposal
defines the extent of an exit to end at the last moment possible
within some particular reference implementation. It has
a cost to implementors whose implementation is not identical to the
reference implementation. Another alternative proposal, not considered
here, would duck the issue by outlawing all nonlocal exits from UNWIND-PROTECT
cleanup forms. That alternative would have a substantial cost to some users.
Scheme is cleaner: it avoids this issue by specifying that the extent
of an exit never ends.
An argument for the MEDIUM proposal was made based on the example:
(block foo
(block bar
(unwind-protect
(return-from foo 'foo)
(return-from bar 'bar))))
Since there is no reason for FOO and BAR not to be treated interchangably,
calling this an error would be inappropriate.
It was argued that the MINIMAL proposal is equivalent to practically
outlawing non-local exits from UNWIND-PROTECT cleanup clauses, because
there is no general way to determine the target of the nonlocal exit
that caused the cleanup clause to be invoked.
CLtL never says in what dynamic environment cleanup forms of
UNWIND-PROTECT are executed. The implementation note on p.142 may have
been intended to cover this, but since it doesn't define the term
"frame" that it uses, it doesn't actually say anything. The extent of
dynamic-extent entities other than exits should be the
subject of a separate proposal. It was argued that the likely
resolution of those issues would be more consistent with the
MEDIUM proposal than MINIMAL.
The following example was offered as an argument against MINIMAL. Given:
(block nil
(handler-case
(unwind-protect (return)
(error "foo")) ;probably an error, under the proposal
(error ()
(print "foo"))))
If the ERROR handler has the same scope and extent a CATCH in the same place
would have (and that seems reasonable, though I'm not certain that the
condition system specifically requires that interpretation), then the handler
will be apparent to the call to ERROR, but will no longer be a valid target
(its extent was exited by the RETURN in the UNWIND-PROTECT body).
----- End Forwarded Messages -----
∂12-Dec-88 1111 X3J13-mailer Issue: FIXNUM-NON-PORTABLE (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 11:10:57 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 DEC 88 11:02:59 PST
Date: 12 Dec 88 10:49 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: FIXNUM-NON-PORTABLE (Version 4)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-110259-4502@Xerox>
!
Issue: FIXNUM-NON-PORTABLE
References: CLtL p. 14, 34, 43, 231
Category: CHANGE, CLARIFICATION
Edit History: Version 1, 11-Jul-88, Sandra Loosemore
Version 2, 15-Sep-88, Masinter
Version 3, 23-Sep-88, Masinter
Version 4, 7-Dec-88, Masinter (two proposals)
Problem Description:
Implementations of Common Lisp are required to support two disjoint
subsets of integers, fixnums and bignums, with the promise that
fixnums have a more efficient representation. However, nothing is
guaranteed about the range of integers which are fixnums: "Exactly
which integers are fixnums is implementation-dependent; typically they
will be those integers in the range -2**n to 2**n - 1, inclusive, for
some n not less than 15."
There are few uses of the fixnum type that are portable, given the
current definition. In particular, many programmers use FIXNUM type
declarations where they really mean "small integer".
While most Common Lisp implementations have a FIXNUM range
which is a subset of integers represeted and operated on most
efficiently, many also have several other subranges. The
partitioning of INTEGER into BIGNUM and FIXNUM is merely
confusing in these implementations, and not useful.
CLtL p14 and p34 disagree about BIGNUM. One says that
FIXNUM and BIGNUM are an exhaustive partition of the
integer space, the other says they might not be!
Proposal: FIXNUM-NONPORTABLE:TIGHTEN-DEFINITION
(1) Change the description of the type FIXNUM to reflect that it is
required to be a supertype of (SIGNED-BYTE 16).
(2) Define BIGNUM to be exactly (AND INTEGER (NOT FIXNUM))
Proposal: FIXNUM-NONPORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
(1) Change the description of the type FIXNUM to reflect that it is
required to be a supertype of (SIGNED-BYTE 16).
(2) remove the type BIGNUM from the language.
Example:
Consider an implementation with three numeric representations:
Fast (INTEGER -1024 1023)
Immediate 29 bits
Extended Multi-precision
Such an implementation would have to define
FIXNUM to be (OR Fast Immediate). BIGNUM, if it
remains, would then refer to multi-precision integers.
Rationale:
Many programmers already use FIXNUM to mean "small integer"; this
proposal makes this usage portable.
However, there is little portable use for the type BIGNUM, and it
is inconsistent with many current implementation techniques.
Removing it is an incompatible change for a weak reason; thus
two proposals.
Current Practice:
Xerox Common Lisp has 17-bit fixnums. Most other Common Lisp
implementations have fixnum ranges of 24 bits or larger. We know
of no implementation that currently violates the proposed minimum
size.
Several existing Common Lisp implementations have more than two
representations for integers, such that the FIXNUM/BIGNUM distinction
is confusing; they define BIGNUM to cover all of the larger number
types.
Cost to implementors:
Slight. All implementations we know of already define FIXNUMs to be at
least 16 bits; TOSS-BIGNUM would have to remove the BIGNUM type
specifier to be in compliance with the proposal.
Cost to users:
Slight. The removal of the BIGNUM type specifier will affect user code
but it appears to be little-used.
Benefits:
The FIXNUM type specifier would have a portable interpretation.
The language would be less confusing.
Discussion:
There was little consensus on whether to leave BIGNUM in the language.
We don't currently have a way to "deprecate" features, so we are not
proposing it here.
Earlier discussion of a related proposal contained several other more controversial
components (adding a constant MAX-INTEGER-LENGTH, allowing
MOST-POSITIVE-FIXNUM to be NIL as well as an integer.) This proposal
is an attempt to address the part that cleanup committee seemed to agree on.
It is possible that an implementation have a single representation for all
integers, and no way to identify any efficient range of integers. Those
implementations might need to set MOST-POSITIVE-FIXNUM
and MOST-NEGATIVE-FIXNUM to arbitrary values, consistent with
the requirement that (SIGNED-BYTE 16) is a subtype of FIXNUM.
Other alternatives considered (and not necessarily mutually exclusive
with this proposal):
remove the FIXNUM type specifier entirely, while leaving a way
to query what is the most efficient range of integers
leave the range of FIXNUMs unconstrained and introduce a
SMALL-INTEGER type with a fixed range (but no promises about
efficiency) .
guarantee that the value of the constant ARRAY-TOTAL-SIZE-LIMIT be a
fixnum (for efficient array addressing)
It might be possible to specify the required performance behavior
of FIXNUMs more concretely, e.g., specify that the basic integer operations
use algorithms that are not proportional to the size of the data; it
should be just about as fast to add numbers in the middle of the fixnum
range as it is to add, say, 10 and 11. This might be a useful way to describe
the intent of the FIXNUM range, if not its specification.
----- End Forwarded Messages -----
∂12-Dec-88 1129 X3J13-mailer Issue: FUNCTION-COMPOSITION (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 11:29:00 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 DEC 88 11:17:46 PST
Date: 12 Dec 88 11:04 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: FUNCTION-COMPOSITION (Version 4)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-111746-4560@Xerox>
!
Forum: Cleanup
Issue: FUNCTION-COMPOSITION
References: None
Category: ADDITION
Edit history: 21-Jun-88, Version 1 by Pitman
05-Oct-88, Version 2 by Pitman
7-Dec-88, Version 3 by Masinter
12-Dec-88, Version 4 by Masinter (additional comments)
Related-Issues: TEST-NOT-IF-NOT
Problem Description:
A number of useful functions on functions are conspicuously
absent from Common Lisp's basic set. Among them are functions
which return constant T, constant NIL, and functions which
combine functions in common, interesting ways.
Proposal (FUNCTION-COMPOSITION:NEW-FUNCTIONS):
Add the following functions:
COMPOSE &REST functions [Function]
Returns a function whose value is the same as the composition
of the given functions. eg, (FUNCALL (COMPOSE #'F #'G #'H) A B C)
is the same as (F (G (H A B C))). Also, for example, #'CAADR may
be described as (COMPOSE #'CAR #'CAR #'CDR).
CONJOIN &REST functions [Function]
Returns a function whose value is the same as the AND of the
given functions applied to the same arguments.
DISJOIN &REST functions [Function]
Returns a function whose value is the same as the OR of the
given functions applied to the same arguments.
COMPLEMENT function [Function]
Returns a function whose value is the same as the NOT of the
given function applied to the same arguments.
ALWAYS value [Function]
Returns a function whose value is always VALUE.
Proposal: FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
Only add the functions COMPLEMENT and ALWAYS.
Examples:
(MAPCAR #'(LAMBDA (X) (DECLARE (IGNORE X)) T) '(3 A 4.3))
==
(MAPCAR (ALWAYS T) '(3 A 4.3))
=> (T T T)
(MAPCAR #'(LAMBDA (X) (AND (NUMBERP X) (ZEROP X))) '(3 A 0.0))
==
(MAPCAR (CONJOIN #'NUMBERP #'ZEROP) '(3 A 0.0))
=> (NIL NIL T)
(FIND-IF #'(LAMBDA (X) (AND (INTEGERP X) (SYMBOLP X))) '(3.0 A 4))
==
(FIND-IF (DISJOIN #'INTEGERP #'SYMBOLP) '(3.0 A 4))
=> A
(FUNCALL #'(LAMBDA (&REST X) (REVERSE (APPLY #'LIST* X))) 3 4 5 '(6 7))
==
(FUNCALL (COMPOSE #'REVERSE #'LIST*) 3 4 5 '(6 7))
=> (7 6 5 4 3)
(FIND-IF-NOT #'ZEROP '(0 0 3))
==
(FIND-IF (COMPLEMENT #'ZEROP) '(0 0 3))
=> 3
Rationale:
The presence of these functions will contribute to syntactic
conciseness in some cases. The NEW-FUNCTIONS proposal
will permit a programming style which is currently awkward
in most Common Lisp implementations.
Current Practice:
No Common Lisp implementations provide these functions,
but they do exist in the T language.
Cost to Implementors:
A straightforward implementation is simple to cook up. The definitions
given here would suffice. Typically some additional work might be
desirable to make these open code in interesting ways.
(DEFUN COMPOSE (&REST FUNCTIONS)
(COND ((NOT FUNCTIONS)
(ERROR "COMPOSE requires at least one function."))
((NOT (REST FUNCTIONS))
(FIRST FUNCTIONS))
(T
(LET ((REVERSED-FUNCTIONS (REVERSE FUNCTIONS)))
(LET ((LAST-FUNCTION (FIRST REVERSED-FUNCTIONS))
(OTHER-FUNCTIONS (REST REVERSED-FUNCTIONS)))
#'(LAMBDA (&REST ARGUMENTS)
(DO ((O OTHER-FUNCTIONS (CDR O))
(VAL (APPLY LAST-FUNCTION ARGUMENTS)
(FUNCALL (CAR O) VAL)))
((NULL O) VAL))))))))
(DEFUN CONJOIN (&REST FUNCTIONS)
#'(LAMBDA (&REST ARGUMENTS)
(DO ((F FUNCTIONS (CDR F))
(VAL T (AND VAL (APPLY (CAR F) ARGUMENTS))))
((OR (NULL VAL) (NULL F)) VAL))))
(DEFUN DISJOIN (&REST FUNCTIONS)
#'(LAMBDA (&REST ARGUMENTS)
(DO ((F FUNCTIONS (CDR F))
(VAL NIL (OR VAL (APPLY (CAR F) ARGUMENTS))))
((OR VAL (NULL F)) VAL))))
(DEFUN COMPLEMENT (FUNCTION)
#'(LAMBDA (&REST ARGUMENTS)
(NOT (APPLY FUNCTION ARGUMENTS))))
(DEFUN ALWAYS (VALUE)
#'(LAMBDA (&REST ARGUMENTS)
(DECLARE (IGNORE ARGUMENTS))
VALUE))
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
(COMPLEMENT BENEFITS)
Benefits:
Some code would be more clear.
Some compilers might be able to produce better code.
Takes a step toward being able to flush the -IF-NOT functions
and the :TEST-NOT keywords, both of which are high on the list
of what people are referring to when they say Common Lisp is
bloated by too much garbage.
Aesthetics:
In situations where these could be used straightforwardly, the
alternatives are far less perspicuous.
Discussion:
It is technically possible to define this functionality portably,
the really important part of this proposal is that native compiler
support is needed to really do them justice. Portable implementations
are not likely to be efficient enough for serious use.
Placing these functions in the core language not only permits
but encourages a very useful set of compiler optimizations that
would otherwise be difficult to obtain.
In principle, a proposal to flush the :TEST-NOT keywords and the
-IF-NOT functions could even be entertained if the COMPLEMENT
function were added. [See issue TEST-NOT-IF-NOT.]
Pitman and van Roggen support the proposal.
Jim McDonald (JLM@Lucid.COM) seemed supportive of this proposal
and even suggested adding more elaborate operators such as
PERMUTE and COMMUTE. eg, (COMMUTE #'CONS) would be like what
Maclisp called XCONS.
Other comments:
"I don't like it. I really don't."
The names chosen are too "generic"; pick other names.
No existing implementations have functions like these, although they
could easily have added them.
If COMPOSE is added, deal with multiple values, e.g.,
(funcall (multiple-value-compose #'f #'g #'h) a b c)
is the same as
(multiple-value-call #'f
(multiple-value-call #'g
(h a b c)))
"this is the sort of gratuitious addition to the
language that ought to be tested first -- tested by it's utililty to some
vendor/implementor who feels it's worth the risk to add something like it
to his product. I deplore the tendency to think that vendors shouldn't make
an offering unless it is "sanctioned" by the X3J13 committee."
Additional Comments:
"The names are OK with me except for ALWAYS. ALWAYS reminds me of the
SOME/EVERY/etc. mapping functions, perhaps because it's a LOOP keyword
(btw, what's the status of LOOP keywords?). I would prefer something
like RETURNER. Also, I presume it's defined as taking (&rest ignore)
for an arglist. Is that true? Shouldn't that be specified in the proposal?"
"Although the discussion mentions some criticism from within the subcommitte,
I don't think it does full justice. ....
. . .
I say "gratuitious" because
(1) no vendor/implementor supplies them now; thus it is not "existing
practice" that needs to be standardized;
(2) no fundamental problem has been exposed because of its lack; no
implementational headaches would be resolved, and few (if any) pleas
from the user community would be addressed;
(3) no confusions exists among our community as to what these functionals
(or similar such features) mean; hence no need to clarify.
. . .
While it is useful to encourage the "functional style" of programming,
these functions are *not nearly enough* to do that. That is, if you really
wanted to build a useful library, you would find these few functions
inadequate.
Extensions that no current vendor offers -- even those that have extensive
sets of extensions to Common Lisp in their product -- should be viewed with
great suspicion.
"
∂12-Dec-88 1129 X3J13-mailer Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 11:29:08 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 11:19:43 PST
Date: 12 Dec 88 11:19 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (Version 3)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-111943-4569@Xerox>
!
Forum: Cleanup
Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
References: CLtL pp 47-48, 158-159
Category: CHANGE
Related-issues: DECLARE-TYPE-FREE
Edit history: #1, 7 Sept 1988, Walter van Roggen
#2, 13 Sept 1988, Walter van Roggen (costs & proposal limitations)
#3, 7-Dec-88, Masinter
Problem description:
The current description of the specialized FUNCTION type specifier is not very
useful to program analysis tools and is not very intuitive to programmers
because the meaning of the argument type specifiers is not restrictive.
Programmers find it useful to add information about the types of the arguments
a function expects and about the type(s) that a function may return. This
information is useful both to human readers of the code as well as to type
checking programs such as compilers and cross referencers. The only apparent
way of providing this information is with the FTYPE declaration
or the FUNCTION type specifier.
Furthermore, implementations may wish to provide additional optimizations based
on avoiding type checking or different methods of argument passing. These
optimizations require the same sort of information about the argument types.
However, the current definition of FUNCTION type specifiers on pages 47-48 of
CLtL states that a function such as CONS that is of type
(FUNCTION (T T) CONS)
is also of type
(FUNCTION (FLOAT STRING) LIST).
The problem is that the argument types aren't restrictive, so no interesting
matching of types is possible.
Proposal (FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE)
This proposal is written as if DECLARE-TYPE-FREE (Version 6, 06-Oct-88)
is in effect.
Specify that a declaration of the form
(ftype (function (arg0-type arg1-type ...) val-type) f))
implies that any call of the form (f arg0 arg1 ...) within the scope of
the declaration can be treated as if it were
(the val-type (f (the arg0-type arg0) (the arg1-type arg1) ...))
That is, it is an error for any of the arguments not to be of the specified
types or the result not to be of the specified type. (In particular,
If any argument is not of the correct type, the result is not guaranteed
to be of the specified type.)
Thus, an FTYPE declaration for a function describes calls to the function,
not the actual definition of the function.
Similarly, specify that a declaration of the form
(type (function (arg0-type arg1-type ...) val-type) fn-valued-variable)
has the interpretation that, within the scope of the declaration, it
is an error to call the value of fn-valued-variable with arguments
not of the specified type; assert that the value resulting from a valid
call will be of type val-type.
As with variable type declarations (cf DECLARE-TYPE-FREE), nested declarations
imply intersections of types, as follows:
If two (or more) declarations of the form "ftype" are in effect,
(ftype (function (arg0-type1 arg1-type1 ...) val-type1) f))
and
(ftype (function (arg0-type2 arg1-type2 ...) val-type2) f))
then within the shared scope of the declarations, calls to f can be
treated as if it were declared
(ftype (function ((and arg0-type1 arg0-type2) (and arg1-type1 arg1-type2 ...) ...)
(and val-type1 val-type2))
f))
(It is legitimate to ignore one or all of the declarations in force.)
If two (or more) type declarations are in effect for a variable, and
they are both FUNCTION declarations, the declarations combine similarly.
This proposal does not alter the status (or lack thereof) of other issues
related to FUNCTION type specifiers: what lambda-list keywords mean, what the
VALUES type means, what implications there are w.r.t. argument counts, doing
multiple PROCLAIMs, doing local DECLAREs that shadow other declarations or
proclamations, describing generic functions incrementally, the result of TYPEP
with a specialized FUNCTION type, or the nesting and scoping rules for
FTYPE declarations.
Example:
(DEFUN FFF (F)
(DECLARE (TYPE (FUNCTION (FLOAT STRING) LIST) F))
... (FUNCALL F (FOO ...) ...) ... )
then #'CONS is a valid argument to be passed to FFF because the declared
type of the argument is consistent with type (FUNCTION (T T) CONS).
Within FFF, the declaration permits us, for example, to assume that FOO
returns a FLOAT.
Rationale:
The proposal seems most like what users expect.
Current Practice:
VAX LISP assumes and makes use of the semantics different than CLtL
but not exactly what is specified here. Lucid
has a RESTRICTIVE-FTYPE declaration with these semantics and ignores the
standard FTYPE declaration. Gold Hill intends to use these declarations in this
manner. Many implementations don't make use of these declarations. At least
several users make use of declarations assuming the new semantics.
Cost to Implementors:
Since most implementations don't make use of function declarations, and since
those known to do so can be changed easily, the cost should be minimal.
Cost to Users:
There may be some existing "imprecise" function declarations. However, the
natural tendency when providing these declarations is to be as "descriptive"
(i.e., restrictive but complete) as possible, both for documentation purposes
as well as for potential compiler benefits. There cannot have been any uses of
the specialized FUNCTION type for discrimination. Thus most existing uses are
probably compatible with this new definition.
Cost of Non-Adoption:
There already exists user code on many implementations that assume the
proposed semantics. Not adopting this proposal would continue to render
such code incorrect or at least non-portable.
Benefits:
Better type checking and more compiler optimizations should be possible.
Esthetics:
This is the what most programmers expect the specialized FUNCTION type to
mean, particularly those coming from other languages.
Discussion:
A declaration of
(FUNCTION (FIXNUM FIXNUM) CONS)
is a not proper global declaration for CONS if any program might
call CONS with arguments that are not FIXNUM.
The list form of the FUNCTION type specifier is different from most
type specifiers because it cannot be used for discrimination.
Thus, the notion of "subtype" does not make sense, since assertions
about the functional value of a variable are only partially
about the actual value of the variable and mainly about the
values that might be passed to the variables (function) value.
∂12-Dec-88 1212 X3J13-mailer Issue: HASH-TABLE-STABILITY (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 12:12:16 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 11:51:33 PST
Date: 12 Dec 88 11:51 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: HASH-TABLE-STABILITY (Version 1)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-115133-4704@Xerox>
This issue has "additional comments" at the end that are not
part of this version.
!
Issue: HASH-TABLE-STABILITY
References: CLtL, p.282 "Hash on Lisp object"
The Art of Computer Programming, vol 3, Section 6.4 "Hashing"
Category: CLARIFICATION
Edit history: Version 1, 11-Nov-88, by JonL
Problem description:
The performance, and to some degree the semantics, of hash tables
depends not only on the kind of table as specified by the :test
argument to MAKE-HASH-TABLE, but also on the underlying techniques
of key transformation (into an integer) and of "collision" resolution.
CLtL is not specific enough to encompass current, desirable practice.
People tend to be confused as to what "Hash on EQ" means, both in terms
of semantics and expected performance. Many will often suggest using
SXHASH as the key-transformation function for EQ/EQL type tables, in
order to circumvent the well-known GC-related problem with those tables.
[See, for example, the message from Barry Margolin to the common-lisp
mailing list dated "12 Sep 88 11:05 EDT"; it is reproduced at the end of
the Discussion section below.] Unfortunately, this suggestion violates
the commonly perceived notion of what "Hash on EQ" means, even though
CLtL nowhere explicitly would rule it out. CLtL is not precise enough
as to what is expected of these types of tables, and certainly the
phrase "commonly perceived notion" is not precise enough.
A similar ambiguity can arise as to what "Hash on EQUAL" means; CLtL
p.285 only indirectly implies that SXHASH should be used as the
key-transformation function for EQUAL type tables. [See below for
definition of "key-transformation".]
The term "Hashing on Lisp objects" has come to be called "Hash on EQ",
and "Hashing on Tree Structure" is called "Hash on EQUAL"; see CLtL
p.282 , which describes the differences between hash-table kinds as
being merely which function they use as the equivalence predicate
(the :TEST function argument to MAKE-HASH-TABLE.) However, the term
"Hash Table" carries a strong connotation about how such a table is
implemented; in particular, for sufficiently large tables, some technique
for "collision resolution" must be done. (See Knuth vol 3, p507-8).
Since CLtL merely focuses on the :test function, people -- implementors
as well as end-users -- tend to be confused as to how these techniques
play a central part in the notion of "hash tables; furthermore, CLtL is
silent about what actions must preserve the stabililty of these
"collision chains" (i.e., the ability of the table to "find" previously
entered keys).
Proposal (HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS)
Summary of proposals:
-- Clarify that by "hashing", we mean more than simple linear search.
-- Generalize the following requirement from CLtL p.285:
(EQUAL X Y) implies (EQUAL (SXHASH X) (SXHASH Y))
and clarify that this requirement exactly prescribes how sensitive
hash tables can be to user-initiated data modifications.
-- Characterize just what key-transformation functions may be used for
EQ, EQL, EQUAL and EQUALP hash tables.
First, some terminology:
"Key-Transformation". This is a term used by Knuth to describe the
homomorphic transformation of a hash-table key argument into an integer.
[See the index for "The Art of Computer Programming", vol 3; especially
see Section 6.4 and page 512.] It also can refer to the transformation
into a set of two or more integers (which is not really a distinct
notion considering Goedel numbering). From this integer, the pattern
of table indices to use when searching for that key will be completely
characterized. Knuth also uses a related term "hash function" to mean
"the address where the search begins"; that term is much too subject to
confusion, and will not be used herein.
"Collision Chain". This term is limited in use by Knuth to just one
particular method of collision resolution; herein it will be used to
describe the sequence of probes specified for a given candidate entry
by a particular key-transformation; i.e. a virtual "chain" of table
indices (or address) to be examined. Two different objects which "hash"
to the same table address are "in conflict", and their respective
collision chains may or may not be equal.
"Expected number of (re-)probes". A particular algorithm for key-
transformation and collision-chain specification could be analyzed to
show a graph of the "Expected" number of calls on the :test function,
as a function of the fullness of the table (number of entries divided
by table size). "Expected" has a technical, mathmatical meaning here:
it basically means "average", so one must be careful not to get carried
away with particular counter examples of "badly distributed" data. A
"probe" is one comparison of the argument with the key of an entry in
the table, using the test function.
"%UNIQUE-NO". The implementation of Lisp data, encoded into machine-
specific data and addresses, is not part of the portable specification
of CL; but we are aware that every implemetation _must_ do some such
embedding. Thus we will use %UNIQUE-NO to name a one-to-one function
which maps any Lisp object into a Lisp integer. Normally, this will
just be the machine address of where the object is stored, possibly with
some data-type tag bits added. But for non-stored, or "immediate" data,
it doesn't matter what %UNIQUE-NO returns as long as its bijective nature
is maintained. The following equivalence is a defining characterization:
(eq x y) <--> (= (%unique-no x) (%unique-no y))
Now for the actual proposals.
1. Clarify that the term "hash table" implies the use of some techniques
designed to make the expected number of probes be bounded by a small
constant rather than growing linearly with the number of entries in the
table [for "small constant", one could also accept "log of the number of
entries"]. Although nothing in CLtL explicitly prohibits it, very few
people would accept simple linear searching as any kind of hash table.
For example, the following definition is counter to our understanding:
(defun gethash (x ht &optional default)
(let ((index (position x (hash-table-key-vector ht)
:test (hash-table-test ht))))
(if index
(values (svref (hash-table-value-vector ht) index)
T)
(values default
NIL))))
Such a simple definition may be functionally useful when the total
number of entries is small (e.g., a couple dozen or so); but the
"Expected" number of probes grows linearly with the number of entries.
As a consequence of this requirement, the collision chain for a give item
in a given table will likely not cover the whole table; otherwise, if
every such chain covered a substantial fraction of the table, then the
behaviour time would be linear in the size of the table. Thus it should
be noted that even though an item is entered in a hash table, it
typically _cannot_ be found by searching through the wrong collision
chain.
2. Specify that for any equivalence relation <eqv> used as a hash table
:test function, there must be a corresponding key-transformation function
<sxh> used in that hash table such that the following implication is true
for all X and Y:
(<eqv> x y) --> (= (<sxh> x) (<sxh> y))
This could be said to mean that a key-transformation function must be "not
more discriminating" than the equivalence function it is associated with;
i.e. as a numerical function, it must not create more equivalence classes
of data than the associated equivalence function does.
This requirement resembles that placed upon SXHASH [CLtL, p285], and
from it, one may deduce that SXHASH is a acceptable key-transformation
function for EQUAL type hash tables. Note well, however, that there
are many many functions satisfying this property for EQUAL. Hence
key-transformation for EQUAL tables:
(1) need not be constant over all CL implementations;
(2) need not be constant over all instances of EQUAL hash-tables in
a given implementation;
(3) need not be constant even over all entry counts for a particular
hash table in a given implementation.
Note also that this requirement -- "not more discriminating" -- rules
out the use of key-transformations which "notice" data modifications
that are not likewise "noticed" by the test function. Since user-
initiated data modifications might conceivably affect either the
equivalence relation of a hash-table (the :test function) or the
associated key-transformation function, we want to ensure that the
ability of the table to "find" a previously entered key is related only
to the ability of the :test function to identify equivalent copies of
the key.
3. Clarify that %UNIQUE-NO is acceptable as a key-transformation for an
EQ type table, but that it is not suitable for EQUAL or EQUALP tables.
Clarify also that most SXHASH implementations are _not_ suitable for EQ
or EQL type tables.
Numerous implementations have some function like %UNIQUE-NO called
either %POINTER or POINTER-TO-FIXNUM; they are generally acceptable for
EQ type tables. But one must be careful to note that similar, unrelated
functions could also be used; in particular, many "unique identification"
schemes have been employed where the integer is cached with the object by
some means other than the bits of its address (e.g. a "hidden" component
inside the object). Of course, any %UNIQUE-NO defined as above would not
be acceptable for EQUAL or EQUALP tables; two EQUAL but non-EQ cons cells
must have different %UNIQUE-NO values, violating the general rule stated
in item 2 above.
A trivial variant on %UNIQUE-NO is acceptable for EQL tables:
(if (numberp x) (sxhash x) (%unique-no x))
By itself, %UNIQUE-NO would not be acceptable since it would be too
"discriminating" on numbers.
Many persons have noted that the definition:
(defun sxhash (x) 5) ;for any random integer value of "5"
meets the CLtL criterion for SXHASH. In fact, such a constant function
may be quite useful for hash-tables with entry counts below a specified
mininum. But of course it is not really suitable in general since it
would put every entry into the same collision chain; that would cause
the expected re-probe cost to be linear in the number of entries, which
violates item 1 above.
On the other hand, an SXHASH function suitable for use as the key
transformation in an EQUAL type table is _not_ acceptable for use
with an EQ or EQL table. Every implementation the proposer has queried
returns different values for the lists (A) and (B). Thus consider the
example of hashing a list (A) into an EQ type table, and observe what
happens after altering the (first) element of this list to be B. Let
x = the list before modification
y = the list after modificaton
now clearly (EQ X Y) is true, so we would obviously like a GETHASH call
after the modification has been done to find the same cons cell that
had been entered before the update. If SXHASH were used as the key-
transform, then the collision chain selected _after_ the alteration would
be different from the one selected beforehand. Since the two different
collision chains can not be guaranteed to intersect, then in at least
some circumstances, GETHASH on X would find the entry, but GETHASH on Y
would fail to find it. See also the examples section.
Although SXHASH is not very tightly defined in CLtL, one must be careful
not to make assumptions about whether or not it is acceptable for use in
EQUALP tables. In order to get a reasonable amount of randomization in
the collision chains, a key-transformation function for EQUAL tables
ought to be "more discriminating" than any minimal function acceptable
for EQUALP tables [because EQUAL partitions the object world up into
many more equivalence classes than does EQUALP].
In item 2 above, there are listed three areas where key-transformation
functions may differ: when going from one vendor to another (or from one
release by the same vendor to another), when going from one hash-table
to another of the same type, and when increasing or decreasing the entry
count of the table. To this list we can add another more general rule on
key-transformations.
(4) [they] need not be constant even over a particular "core image"
saving and restoration, or over a "memory reorganization" such as
a garbage collection.
Of course, if a change is made at some point in time in the key-
transformation algorithm being used for a particular table, then that
table should be "re-hashed" to ensure the continuity of its entries.
As has been noted before, many implementations use algorithms for EQ
type tables which change after any data is relocated; that is why
re-hashing may be required after a "GC".
Examples:
It is not surprising that in the following example, the value Y
cannot be found in the table after it has been altered by the first
SETF, even though it could be found before the alteration.
(setq ht (make-hash-table :test 'equal)) ==> #<Hash-Table>
(setq x '(A (B) (C D))
y (copy-tree x)) ==> (A (B) (C D))
(and (equal x y) (not (eq x y))) ==> T
(setf (gethash x ht) T) ==> T
(setf (car (second y)) 'E) ==> E
(gethash x ht) ==> T
(gethash y ht) ==> NIL
After all, the :test function will not be able to identify the
altered key with with the one originally entered, because at the
time gethash is called:
(equal x y) ==> NIL
However, the circumstances under which the following can fail are
not at all obvious:
(setq ht (make-hash-table :test 'equal)) ==> #<Hash-Table>
(setq x '(A #(B) (C D))
y (copy-tree x)) ==> (A #(B) (C D))
(and (equal x y) (not (eq x y))) ==> T
(setf (gethash x ht) T) ==> T
(setf (aref (second y)) 'E) ==> E
(gethash x ht) ==> T
(gethash y ht) ==> ?
Note however that:
(equal x y) ==> T
If the key-transformation function used in this hashtable failed to obey
the "not more discriminating" contraint imposed by item 2 above, it
might be tempted to descend into the vector #(B) in order to randomize
the keys a bit more; but EQUAL on pointer vectors is defined to be EQ.
Thus X and Y, while being EQUAL, might fall into different collision
chains, and hence not be identified as the same key.
On the other hand, EQ/EQL type tables should be impervious to the
updates in the above examples:
(setq ht (make-hash-table)) ==> #<Hash-Table>
(setq y (setq x (copy-tree '(A (B) (C D))))) ==> (A (B) (C D))
(setf (gethash x ht) T) ==> T
(gethash x ht) ==> T
(setf (car (second y)) 'E) ==> E
(gethash y ht) ==> T
Thus x and y are "EQ, but not EQUAL" [which only makes sense when
they refer to the same object at different points in time]; however,
the EQ/EQL-type table is not affected by this.
Rationale:
The performance expectations about hash-tables, and consequent
implementational constraints, need to be formalized.
Current practice:
Every implementation that the proposer has tried *seems* to satisfy
these constraints.
Cost to Implementors:
None.
Cost to Users:
None.
Cost of non-adoption:
Continuing confusion as to what is stable in EQ/EQL tables, and what
is stable in EQUAL tables. Possible confusion when it comes to
implementing EQUALP tables.
Performance impact:
N.A.
Benefits:
See Cost of non-adoption.
Esthetics:
The proposal more closely relates the term "Hash Table" to the
classic use of it in "The Art of Computer Programming", vol 3.
Discussion:
One of the attractions to Common Lisp is that many common techniques are
a required part of the language; C programmers who continue to re-invent
hasing techniques over and over have praised CL in particular for hash
tables. After all, it is much more likely that efficient, correctly
coded algorithms will be provided by the system supplier than that every
code writer will understand and correctly apply the information found
in Knuth's "The Art of Computer Programming", vol 3.
The requirement that the expected number of reprobes be bounded by a
"small constant" should not be taken to extreme. In particular, a
simple trade-off of space for time can assure some compliance with it.
For example, a data set of size N could be partitioned into N/20
subsets; as long as the partitioning function does a fairly good job
of balancing the number of elements in each partition class, and as
long as the partition function can be quickly calculated, then the one
could say that the expected number of probes would be bounded by "about
twenty or so". The generally understood meanings of the :rehash-size
and :rehash-threshold components of hash-tables may be biased towards
an "open-addressing" implementation; but "bucketizing" implementations
are not arbitrarily ruled out. This proposal is in no way intended to
rule out "bucketizing" implementations of hash tables.
Here's an example of how one might analyze the problems relating GC
and EQ/EQL type tables:
Date: Mon, 12 Sep 88 11:05 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: MAKE-HASH-TABLE :TEST arg
To: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Cc: common-lisp@sail.stanford.edu
. . .
Various aspects of the behavior of a hash table are dependent upon the
TEST argument. An EQUAL hash table need not be rehashed after a copying
GC. The hash function is generally dependent upon the test function;
for an EQUAL hash table it would be SXHASH, while for an EQ hash table
it would probably be a simple hash on the address.
I suppose you COULD use SXHASH for all hash tables, since EQ objects are
necessarily EQUAL, and you COULD rehash ALL hash tables. Or you could
implement hash tables without actually hashing (e.g. implement them as
alists). But if performance is an issue (which it generally is when you
use a hash table), you'll probably want to do things dependent on the
test function.
barmar
This suggestion is not prohibited by CLtL, although it violates the
commonly accepted understanding of what "Hash on EQ" means.
!
----- Additional Comments -----
"This proposal is so long that I got lost while reading it. From the
examples, one would think it was proposing some rules about what users
can expect when they modify objects that are used as keys of hash
tables. However, I couldn't find anything actually proposed about that.
Most of the proposal seems to be about what performance users of hash
tables should expect, but I didn't see anything specific enough that I
could write a Common Lisp program to test whether an implementation
conforms to the proposal.
I think this proposal needs to be shortened and rewritten. I would
prefer to see it speak about the behavior a user can or cannot expect
from a Common Lisp implementation, rather than in terms of internal
details of how Common Lisp might be implemented. The essay on
implementation techniques could go in the discussion section, or could
be published separately, but I don't think it is suitable as a language
specification.
It might be a good idea to break this into two proposals, one on key
modification and a separate one on performance. The reason I say that
is that I think standardizing performance is extremely difficult, and I
would hate to see the problems with that sink the other proposal."
∂12-Dec-88 1212 X3J13-mailer Issue: IN-PACKAGE-FUNCTIONALITY (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 12:12:28 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 12:11:02 PST
Date: 12 Dec 88 12:10 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: IN-PACKAGE-FUNCTIONALITY (Version 4)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-121102-4751@Xerox>
!
Issue: IN-PACKAGE-FUNCTIONALITY
References: IN-PACKAGE (p183)
Category: CHANGE
Edit history: 07-Jul-88, Version 1 by Pitman
7-Oct-88, Version 2 by Masinter (discussion)
8-Dec-88, Version 3 by Masinter
12-Dec-88, Version 4 by Masinter
Related-Issues: DEFPACKAGE
Problem Description:
There are two typical uses for IN-PACKAGE -- to define/create a package
and to select a package. The fact that these two purposes have been
given to the same function has led to reduced error checking.
Proposal (IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY):
Eliminate the ability of IN-PACKAGE to create a package on demand.
Eliminate the :NICKNAMES and :USE arguments to IN-PACKAGE, since they
are no longer needed.
The results of calling IN-PACKAGE if the package does not already
exist are implementation dependent; implementations "should signal"
an error, or otherwise provide the user with a way to recover from
the situation.
Examples:
#1: (IN-PACKAGE 'NO-SUCH-PACKAGE) ;would signal an error
#2: (DEFPACKAGE FOO ...options...) ;defines/creates a package
(IN-PACKAGE 'FOO) ;selects an existing package
Rationale:
This could allow improved error checking and modularity, with only minimal
loss of functionality.
Current Practice:
Probably no one implements this behavior since it's in direct
contradiction of both the definitions and numerous examples in CLtL.
Cost to Implementors:
As written, no change to implementations is required, but many
will want to make IN-PACKAGE signal an error.
This change would be straightforward to implement.
The cost may not be trivial in all cases, but should not be very large.
Cost to Users:
In most cases, minor syntactic changes to some files would be necessary.
In some cases, no changes would be necessary since files may already be
doing IN-PACKAGE in situations where the author is hoping he's made sure
the real package declaration is already loaded.
Cost of Non-Adoption:
Reduced error checking.
Less modular code.
Benefits:
Errors due to demand-creation of a package by IN-PACKAGE without appropriate
uses of the :USE or :NICKNAMES or without appropriate calls to EXPORT, etc.
afterward would be easier to detect.
Modular package declarations would be encouraged.
Aesthetics:
The fact that IN-PACKAGE is currently ambiguous about intent (whether the
package should exist already or not) is clearly not aesthetic. This change
would be an aesthetic improvement.
Discussion:
The dual use of IN-PACKAGE has not been helpful and is confusing.
Some support this only if DEFPACKAGE passes; others would like
to see IN-PACKAGE changed even if DEFPACKAGE were not added to the language.
However, there might be some compilation problems if IN-PACKAGE
changes and MAKE-PACKAGE signals an error if the package exists.
The issue of compile-time processing of package related functions is
complex, and full of a number of compatibility issues. Should we remove
the requirement of special compile-time handling of IN-PACKAGE?
Should we disallow mid-file switching of *PACKAGE* or package
use lists? These issues are not addressed here.
The issue of the "proper" preface for files needs more thought.
Should files that need demand-created packages start with DEFPACKAGE
followed by IN-PACKAGE?
".... unless the file begins with an
IN-PACKAGE, then the DEFPACKAGE form will be read into totally random
package, doing who knows what sort of damage.
Ideally, every file of a multi-file module should begin with an
IN-PACKAGE form to get "in" that module's package. The exceptions
are files which might as start out (IN-PACKAGE "USER"). For example,
the package creator file might look something like:
(in-package "USER") ;guaranteed to exist, and not be harmful!
(defpackage :phlogiston ...)
Another exception might be the DEFSYSTEM surrogate, which also would
start out in the USER package, and simply load the rest of the files."
∂12-Dec-88 1400 X3J13-mailer Issue: MAKE-PACKAGE-USE-DEFAULT (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 14:00:15 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 13:38:46 PST
Date: 12 Dec 88 13:34 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: MAKE-PACKAGE-USE-DEFAULT (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-133846-5027@Xerox>
A number of comments on this version are excerpted
in a section "Additional Comments" at the end.
!
Issue: MAKE-PACKAGE-USE-DEFAULT
References: MAKE-PACKAGE, CLtL p183
"USER" package, CLtL p181
Related issues: PACKAGE-CLUTTER
Category: CHANGE
Edit history: JonL White, 6-Oct-88 (version 1)
Masinter, 8-Oct-88 (version 2)
Problem description:
The proposal in the issue PACKAGE-CLUTTER would specify that
implementation-specific extensions are not in the LISP package.
With that restriction, access to implementation-specific features
is awkward; it is necessary to always name the vendor-specific
extensions in the :USE list of MAKE-PACKAGE or (if the proposal
in DEFPACKAGE is adopted) in DEFPACKAGE.
This forces users of a specific implementation to always have
to type something to get the default set of features for that
implementation, even if they have no intention of writing portable
code.
Proposal MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
Change the specification of MAKE-PACKAGE (and DEFPACKAGE, if
adopted, and IN-PACKAGE, if IN-PACKAGE-FUNCTIONALITY is not
adopted) so that the default for the :USE keyword is
implementation-dependent. Normally, the default will include
the packages containing the implementation-specific features.
Portable programs should instead always specify :USE '("LISP")
explicitly.
Examples:
(package-use-list (make-package "SOME-USER"))
(package-use-list "USER")
Test Cases:
(assert
(subsetp `(,(find-package "LISP"))
(package-use-list (or (find-package "SOME-USER")
(make-package "SOME-USER")))))
Rationale:
Every implementation either already does the equivalent of this, or
else has a confusing assymetry about the USER package (i.e., their
extensions are "available" in USER, but not in SOME-USER).
Current practice:
TI and Lucid's 3.0 versions "implement" this proposal in that they set
the default :USE argument to be a list of the LISP package and the
implementation-specific package.
In VAXLISP the LISP package is the implementation-specific
package, which contains the 775 symbols supposed to be in the LISP packge
along with all the extensions; the package named COMMON-LISP
has only the 775. Thus this implements the proposal in the sense that
the inheritance of a package made with a default :USE list contains
all the implementation-specific symbols -- not just the 775 "LISP" ones.
Symbolics release 7, and Lucid's 2.1 release use only '("LISP") for the
default MAKE-PACKAGE use list, but have the aforementioned assymetry
about the USER package.
Cost to Implementors:
None; this relaxes a constraint imposed by CLtL.
Cost to Users:
In theory, every user porting code from one vendor to another would
have to ensure that every package definition, via IN-PACKAGE or
MAKE-PACKAGE, had an explicit :USE list. This is probably at most
a 5-minute text editor search. But in fact this imposition is moot,
since virtually every such user has *already* supplied explicit
:USE lists; given the current practice, he has had no alternative.
Cost of non-adoption:
There will continue to be a lack of clear standardization in this area,
especially since vendors are more willing to violate this apparently
unuseful mandate from CLtL than they are to give up a minor bias towards
their customer base.
Performance impact:
None.
Benefits:
This new default behaviour for package creation will permit
documented extensions to appear on equal footing with the basic facilities
in the LISP package. It appears as though the _majority_ of any
users are developing and running their code totally within the
enviornment provided by that one vendor; hence it seems reasonable for
implementations to bias their default use list towards those making
frequent use of their specific extensions to Common Lisp.
Esthetics:
Some feel that fewer implementation-dependent loopholes in the language
is preferable, even when the practical import is virtually moot.
Discussion:
Lucid "exposes" the default :use list as the value of the special
variable *DEFAULT-MAKE-PACKAGE-USE-LIST*, so that at site-configuration
time, one could do
(setq *DEFAULT-MAKE-PACKAGE-USE-LIST* '("LISP"))
to return to the 1984 CLtL behaviour. [This is not being proposed
at this time.]
----- Additional Comments -----
" I don't like this proposal, but I made a note to myself about another
reason that just occurred to me: There is no syntax for getting the default
(ie, system-dependent) package included if you want to -also- use some other
package."
- - - - - -
"MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT is okay with me.
I think it might be better to strengthen it and say that the
default for :USE is identical to the use list of the USER package.
Does anyone agree?
In response to Kent's remarks, the issue is whether the default should
be a portable way to get the local extensions, or a portable way to
get the portable language without the extensions. I think either of
those choices is portable and reasonable, it just depends on what you
want to make easier, which probably depends on whether a package is
being set up for use only by a predefined program or for use by user
typein and/or user-written programs, either of which are likely to
expect the local extensions.
Hence I would also accept a proposal to make the default for :USE
continue to be the LISP package, rather than incompatibly changing it,
and add a portable name for the local extensions."
- - - - - -
"re: I think it might be better to strengthen it and say that the
default for :USE is identical to the use list of the USER package.
Does anyone agree?
I agree, sort of. Especially since one of the motivating factors for
this proposal was that some Lucid 2.1 user's were complaining that
"things" look a lot different from the USER package than from a
user-created package.
The only question is whether or not you really want the default to be
sensitive to subsequent alterations of USER's :use list. As mentioned
in the Discussion section of the proposal, Lucid's implementation
exposes the default as the value of a global variable, which happens
to be a copy of the initial :use list of USER; but subsequent changes
to USER have no affect on this global variable."
- - - - - -
"The point: non-portable programs should declare that intent up-front.
This is a virtue of the current situation: if the program uses a
non-portable package, they have to state that at the head of the file. Us
poor losers who try to load it into the wrong environment get a error
before we've gotten on with the load."
∂12-Dec-88 1400 X3J13-mailer Issue: PACKAGE-CLUTTER (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 14:00:29 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 DEC 88 13:45:36 PST
Date: 12 Dec 88 13:44 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: PACKAGE-CLUTTER (Version 6)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-134536-5049@Xerox>
!
Issue: PACKAGE-CLUTTER
References: LISP, USER, SYSTEM packages (p181)
Related issues: LISP-SYMBOL-REDEFINITION, DEFPACKAGE,
MAKE-PACKAGE-USE-DEFAULT, IN-PACKAGE-FUNCTIONALITY
Category: CHANGE/CLARIFICATION
Edit history: 07-Jul-88, Version 1 by Pitman
23-Sep-88, Version 2 by Masinter
5-Oct-88, Version 3 by Masinter
7-Oct-88, Version 4 by Masinter (response to KMP)
8-Dec-88, Version 5 by Masinter
(add property lists)
12-Dec-88, Version 6 by Masinter (respond to comments)
Problem Description:
CLtL specifies that
``The package named LISP contains the primitives of
the Common Lisp system. Its external symbols include
all of the user-visible functions and global variables
that are present in the Common Lisp system, such as
CAR, CDR, *PACKAGE*, etc. Almost all other packages will
want to use LISP so that these symbosl will be accessible
without qualification.''
It specifies "all" but not "all and only".
Some implementations place their extensions in the Lisp package.
Nothing in CLtL explicitly prohibits this, but it leads to problems
in general. For example:
- A user defining a function by a name not mentioned in CLtL may be
surprised to clobber a system function in some implementations
- In one particular implementation, the variable HELP was a system
constant, so that ((LAMBDA (HELP) ...HELP...) "Press ? for help.")
signalled a correctable error (asking what variable to bind
instead of HELP :-).
Proposal (PACKAGE-CLUTTER:REDUCE):
Specify that, not only must the LISP package contain at least all of the
symbols listed in the standard, it will have no other external symbols.
(The LISP package may have additional internal symbols.)
External symbols of the LISP package may have function, macro, or
special form definitions, top level value or SPECIAL proclamations,
or type definitions only if explicitly permitted in the specification.
That is, a program is valid Common Lisp if it assumes that
this is true; for example, FBOUNDP will be false for all
external symbols of the LISP package except those documented
to be functions, macros or special forms; BOUNDP will be false
for all those except those documented to be variables,
and portable programs can use symbols in the LISP package
as local lexical variables with the presumption that the variables
are not proclaimed special, except for those variables specified
as constants or variables.
A valid implimentation may have or put additional properties
on symbols (even user created symbols) as long as the
property indicators are not in the LISP, KEYWORD or USER
package.
This proposal constrains implementations as to what their
initial package configuration must be. That is, valid programs
can assume that the conformal Lisp implementation will not
have prohibited properties. The proposal LISP-SYMBOL-REDEFINITION
addresses the converse; that is, what user programs are allowed
to do.
Eliminate the requirement that the initial Common Lisp system
have a package named "SYSTEM". Specify that implementations may
have several other packages available, that these should be
documented. If it is appropriate, the standard might contain
as an example that implementations might have a package named
"SYSTEM".
Clarify that the "USER" package may have additional symbols interned
within it and that it may :USE other implementation-specific packages.
Examples:
#1: The symbol HELP may not be on the LISP package because it is not
mentioned in CLtL.
#2: The symbol VARIABLE is specified to be on the LISP package (because
it is a valid second argument to the DOCUMENTATION function). Since
it is not defined as a variable, type, or function, however, it will
not initially be bound, defined as a type, or defined as a function,
macro or special form.
Rationale:
If extra symbols are permitted in the LISP package, users may be surprised
by relationships between the LISP package and other packages which they
did not expect, or may be surprised by functionality that they did not
expect. The degenerate case is:
(DEFCONSTANT LISP:A 'YOU-LOSE)
(DEFCONSTANT LISP:B 'YOU-LOSE)
(DEFCONSTANT LISP:C 'YOU-LOSE)
...
(DEFCONSTANT LISP:AA 'YOU-LOSE)
(DEFCONSTANT LISP:AB 'YOU-LOSE)
(DEFCONSTANT LISP:AB 'YOU-LOSE)
...etc.
Given such an implementation, even things like (LAMBDA (X) X) are not
valid because they attempt to bind "system constants". It is necessary
that the programmer be able to know for sure that an arbitrary name is
"free for use" and best way to conveniently assure this is to require
that the LISP package be unadulterated.
As for the additional definitions, there are situations where additional
definitions would cause a problem. For example, if a symbol on the Lisp
package were declared as a special variable even though that value was
not mentioned in the standard, that variable would behave incorrectly when
used as a lexical variable. Similarly, if a symbol in the lisp package
were defined as an implementation-dependent special form, problems might
result if a user redefined or even bound (as by FLET or MACROLET) that
name.
The LISP package is the foothold from which portable programs establish
their desired environment. Careful control is desirable to make sure
everyone is starting off on the right foot.
Current Practice:
Some implementations have been known to add additional symbols (usually
functional and/or variable extensions) to the LISP package.
Several implementations have restricted the LISP package to only contain
those symbols in CLtL. (The exact set was difficult to extract because not all
LISP package symbols appeared in the index of CLtL.)
Even in those implementations that have only the prescribed symbols in CLtL,
there can be extra definitions for those symbols. For example, in Symbolics Genera,
the symbols EVALHOOK, ROOM, and APPLYHOOK
are spuriously defined as special variables, and the symbol LAMBDA is defined
as a macro.
Performance Impact:
None
Cost to Implementors:
The actual cost of moving the symbols out of the LISP package in cases
where they are not already gone is quite small. However, if any
implementation really has to do this, it may have a number of suppositions
about what is in what package, and the changes could potentially be extensive.
Cost to Users:
This change is upward compatible with any portable program, but users
of a particular implementation's extensions may be forced to find their
functions in a different package, so there may be a measurable practical
cost.
In many cases where an extension symbol FOO is simply expected to have
been directly available (due to :USE "LISP"), it will work to just just
do (IMPORT 'new-home-package-for-foo:FOO) where the user's package is
declared.
More likely the extension symbols would be moved to one or more
extensions packages, e.g. ACME-COMMON-LISP, so user packages in which
the extensions were desired could simply :USE the extensions package(s).
Implementations might want to use this way of conforming with this
proposal in order to minimize cost to users.
In many cases where an extension symbol FOO is used by explicit package
prefix, such as LISP:FOO, it should be easy to search for `LISP:FOO' or
even `LISP:' to find the cases.
Cost of Non-Adoption:
The potential for the LISP package to be adulterated and for supposedly
portable programs to have difficulty getting a foothold in some
implementations will be `noticeably non-zero'.
Benefits:
Portability of some programs will be enhanced.
Aesthetics:
This change probably supports the naive expectation of most programmers
writing portable code.
Discussion:
This proposal basically affects what implementors are allowed to do;
it says that portable programs can rely on a standard initial package
structure with the same symbols in it. A separate proposal,
LISP-SYMBOL-REDEFINITION, discusses the restrictions on portable
programs as far as redefining LISP symbols.
Whether the USER package may contain symbols other than those
specified in the standard was controversial. The smart programmer
of portable code will never rely on the contents of the
USER package. However, if someone wants a completely empty
package that uses only Lisp, it's easy and portable to create one.
While it would improve portability slightly to disallow additional internal
symbols in the LISP package (since it affects what DO-SYMBOLS will do)
explicitly prohibiting a common practice didn't seem like the best way
to discourage a possibly troublesome implementation technique.
Implementors should be especially careful about accidentally
exporting unwanted additional definitions for symbols,e.g., a variable
definition for EVALHOOK which might show through because of
an unintended name collision.
It is likely that the recently included portions of the standard (CLOS and
the signal mechanism) will reside in their own packages. These externally
defined packages should have the same constraints as outlined for
the LISP package here.
There has been a suggestion that vendor-specific extensions should
be placed in a package named like ACME-COMMON-LISP for the "Acme"
company.
A registry of packages (as well as features, modules and other global
names) would be useful, although probably not a part of the language
standard, per se.
----- End Forwarded Messages -----
∂12-Dec-88 1415 misha@polya.Stanford.EDU Special AFLB tomorrow (don't miss it!)
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Dec 88 14:14:55 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA22276; Mon, 12 Dec 88 14:12:08 PDT
Date: Mon, 12 Dec 88 14:12:08 PDT
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8812122212.AA22276@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: Special AFLB tomorrow (don't miss it!)
There will be a special AFLB tomorrow, Dec 13, at 1:30 in room 252.
The speaker will be Pravin Vaidya from Bell Labs.
Speeding-up linear programming using fast matrix multiplication
Pravin M. Vaidya
AT&T Bell Laboratories,
Murray Hill, NJ 07974
Abstract: We present an algorithm for linear programming which
requires $O(↑(m+n) sup 1.5 ↑n ↑) ↑L)$ arithmetic operations in the
worst case where $m$ is the number of constraints, and $n$ is the
number of variables. The improves on the best known time com-
plexity of linear programming by about $sqrt n$. A key ingredient
in obtaining the speed-up is a proper combination and balancing of
precomputation of certain matrices via fast matrix multiplication and
low rank incremental updating of inverses of other matrices. Speci-
alizing our algorithm to problems such as minimum cost flow, flow
with losses and gains, and multicommodity flow leads to algorithms
whose time complexity closely matches or is better than the time
complexity of the best known algorithms for these problems. (If
time permits I will also discuss some open problems related to linear
programming.)
------------------------------------------------------------------------------
At the usual AFLB time, Dec 15, at 12:30 in room 352, Ilan Vardi
from Stanford will give a talk (if too many people come we may have
to move to a larger room):
A MEDICAL APPLICATION OF COMBINATORIAL OPTIMIZATION
Ilan Vardi
The process of in vivo genetic recombination (IVGR) is well known to
be succeptible to transfer of adventitious viral or bacterial
information (VBI) during invasive chromosomal dispersion (ICD). In
recent years focus has turned to polymer based occlusive sheaths
(PBOS) as a method of preventing VBI during ICD.
In the talk, the question of minimizing the number of PBOS' given
that all dyadic ICD's with IVGR capability are to be performed in a
group of ICD donors (ICDD) and ICD receptors (ICDR) each with a
different VBI so that no VBI is transmitted. Previous work of Hajnal
and Lovasz found upper and lower bounds that differed by an additive
constant of one. I will fill in this gap by providing an algorithm
that gives the optimal solution for any number of ICDD's and ICDR's.
Caveat lector: anyone who doesn't understand this abstract may be
asked to participate in a real time demonstration of the algorithm.
∂12-Dec-88 1434 X3J13-mailer Issue: REQUIRE-PATHNAME-DEFAULTS (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 14:27:43 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 14:26:26 PST
Date: 12 Dec 88 14:26 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 6)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-142626-5215@Xerox>
This issue has consumed a large number of "cleanup" committee
cycles. (I have over 80 messages filed on this one topic.)
We hope to have another proposal available as a possible
resolution of the same issue...
!
Issue: REQUIRE-PATHNAME-DEFAULTS
References: *MODULES*, PROVIDE, REQUIRE, pp 188-191
LOAD, pp 426-427
Category: CHANGE
Edit history: Version 1 by Pierson 9/13/88
Version 2 by Pierson 9/19/88, change PROVIDE stuff per comments
Version 3 by Pierson 10/17/88, remove PROVIDE locaction specs.
Version 4 by Pierson 10/31/88, remove from language
Version 5 by Pierson 11/15/88, cleanup, fix discussion
Version 6 by Pierson 12/9/88, remove *MODULES* as well
Problem description:
PROVIDE and REQUIRE are a dual-purpose pair of functions that attempt
to provide multi-file Common Lisp programs with a single mechanism to
detect and correct incorrect load sequences. These functions were
also designed to be used for general file inclusion in Common Lisp.
Unfortunately, the file loading feature of REQUIRE is specified such
that it is inherently non-portable and environment dependent.
Proposal (REQUIRE-PATHNAME-DEFAULTS:ELIMINATE):
Remove PROVIDE, REQUIRE, and *MODULES* from the Common Lisp standard.
Test Cases/Examples:
(PROVIDE 'fft)
Would not be Common Lisp.
(REQUIRE 'fft)
Would not be Common Lisp.
Rationale:
The file loading feature of REQUIRE is non-portable. The remaining
functionality of PROVIDE and REQUIRE (pushing and testing *MODULES*)
can easily be implemented by user code. Since some implementations
will retain the automatic module loading features of REQUIRE and some
won't, use of REQUIRE will almost always make code less portable.
Current practice:
All implementations currently support some sort of file loading via
single-argument REQUIRE. In general, the Lisp Machine implementations
invoke the system module building/loading facility while the Unix
implementations simply try to load a file in the current directory.
Cost to Implementors:
Implementations will have to move PROVIDE and REQUIRE to their package
for implementation extensions and change their documentation to
indicate that PROVIDE and REQUIRE are non-standard. This is a fairly
small change.
Cost to Users:
Non-portable programs that rely on PROVIDE and REQUIRE will probably
be unaffected since implementations will probably maintain their
existing functionality. Since the current behavior is decidedly
non-portable, portable programs have to aviod or special-case PROVIDE
and REQUIRE anyway.
Cost of non-Adoption:
PROVIDE and REQUIRE will continue as impediments to portability.
Benefits:
The non-portability of PROVIDE and REQUIRE will be made obvious.
Aesthetics:
This simplifies the language by removing an environment-dependent
feature.
Discussion:
The cleanup committee tried to come up with a proposal to restrict
PROVIDE and REQUIRE to the portable subset of their functionality.
This failed because several implementors objected that it compelled
them to significantly reduce the functionality they provided users in
order to create a trivial feature which any user could easily write
for herself.
Fahlman, Gregor, Grey, Loosemore, Moon, Pierson, Pitman, Steele, and
Zacharias have expressed support for removing PROVIDE and REQUIRE from
the language, at least as the lesser of several evils.
JonL would much rather see PROVIDE and REQUIRE remain in the language
as a safety net behind any implementation-specific system building
facility. Pierson likes the safety net idea, but doesn't think it's
workable without forbidding REQUIRE from loading files.
Pitman suggested that PROVIDE and REQUIRE should be depricated rather
than removed entirely. Pierson agrees, but notes that Larry wants us
to deal with deprication versus elimination as a separate global topic.
Several people have expressed a desire not to break existing user
code. If accepted, this proposal should not break existing code
because all implementations are expected to retain their current
PROVIDE and REQUIRE functionality as an extension to Common Lisp.
∂12-Dec-88 1434 X3J13-mailer Issue: PROCLAIM-LEXICAL (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 14:27:29 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 14:10:50 PST
Date: 12 Dec 88 14:08 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: PROCLAIM-LEXICAL (Version 9)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-141050-5132@Xerox>
!
Issue: PROCLAIM-LEXICAL
References: variables (p55), scope/extent (p37), global variables (p68),
declaration specifiers (p157)
Category: CLARIFICATION/ADDITION
Edit history: Version 2 by Rees 28-Apr-87
Version 3 by Moon 16-May-87
Version 4 by Masinter 27-Oct-87
Version 5 by Masinter 14-Nov-87
Version 6 by Pitman 15-Sep-88
(major revision, for review by Jonathan Rees and Jeff Dalton)
Version 7 by Pitman 24-Sep-88
(minor revisions based on comments from Rees and Dalton)
Version 8 by Pitman 06-Oct-88 (merge recent discussion)
Version 9 by Masinter 8-Dec-88 (make JonL's changes)
Problem Description:
Although local variables in Common Lisp may be `special' or `lexical,'
global variables (with the exception of named constants) may currently
only be `special.'
The Scheme language permits free variable references to refer to global
bindings. Their experience suggests that such usage would be useful to
the Common Lisp community. The absence of such a facility in Common Lisp
is a barrier both culturally (to the sharing of ideas) and technically
(to the sharing of code).
SPECIAL proclamations are uncontrollably pervasive. There is no way
to locally override or globally undo a SPECIAL proclamation.
Background/Analysis:
Variable evaluation may be viewed in Common Lisp as a search through
a set of environments to find a binding, and then the dereferencing of
that binding. The environments with which Common Lisp deals are
Lexical (L), Dynamic (D), and Global (G).
A SPECIAL declaration for a variable amounts to a request that the
variable be resolved by searching first the Dynamic and then the Global
environment (DG).
As currently described in CLtL, lexical variable reference searches
only the Lexical environment (L).
Because undeclared free variables in the interpreter are implicitly
declared SPECIAL by most (perhaps all) implementations, this amounts
to a search of Lexical, Dynamic, and Global (LDG). However, the
accompanying warnings in many implementations make it clear that this
behavior is not intended to be taken seriously.
Constants are looked up solely in the Global environment (G). They
have other properties as well, of course.
In the Scheme language, the default lookup is first Lexical, then
Global (LG). Providing compatibility for Scheme code is, and more
generally for a Scheme working style is therefore difficult because
Common Lisp does not provide the LG search style.
The issue of whether a variable can be assigned is orthogonal.
The issue of whether a variable can be bound and, if it can be, which
environment is used for the new binding is orthogonal.
Proposal (PROCLAIM-LEXICAL:LG):
Provide a new declaration (and proclamation) called LEXICAL which implies
LG lookup. That is, variables declared LEXICAL would be looked up first
in the lexical environment (L) and then in the global environment (G)
if not found in the lexical.
Clarify that a dynamic binding of a variable creates a new binding
in the dynamic environment (D) leaving the global environment (G)
unaffected.
Clarify that special variable access does DG lookup. That is,
variables declared SPECIAL would be looked up first in the dynamic
environment (D) and then in the global environment (G) if not found
in the dynamic one. Further clarify that SYMBOL-VALUE does DG lookup.
Define that a lexical binding of a variable creates a new binding
in the lexical environment (L), leaving the global environment (G)
and the dynamic environment (D) unaffected.
Note that an assignment to a variable which is bound in the global
environment (G) will affect lexical (LG) lookups for which there is
no lexical (L) binding and dynamic (DG) lookups for which there is
no dynamic (D) binding.
Note that these restrictions describe an abstract model, not a
concrete implementation. An implementation may still choose to
implement dynamic binding as either deep or shallow, but some
searching may be necessary to find the global cell in shallow bound
implementations [unless dynamic binding has been forbidden for
that variable].
Like SPECIAL declarations (and unlike type declarations),
compilers and interpreters would be required to notice and
respect LEXICAL declarations.
Examples:
#1: (proclaim '(lexical x))
(setq x 1)
(defun f (fn) (list x (funcall fn)))
(defun g (fn)
(let ((x 2))
(declare (special x))
(funcall fn #'(lambda () x))))
(g #'f) => (1 2)
#2: ; Warning: It is unlikely that any serious program would
; be written in so obscure a manner as this example.
; This just tests the fringe cases.
(proclaim '(lexical x))
(proclaim '(special y))
(setq x 1 y 2)
(defun tst ()
(let ((x 3) (y 4))
(locally (declare (special x) (lexical y))
(list x y
(funcall (let ((x 5) (y 6))
#'(lambda () (list x y))))))))
(tst) => (1 2 (5 4))
If the results of this example confuse you, keep in mind
that the results of code like this would be somewhat
confusing no matter what the chosen semantics because the
code itself is far from perspicuous.
An explanation of this behavior, which some people find less
than intuitive because of the bizarre choice of constructs:
X gets bound lexically to 3 because X is [pervasively]
proclaimed LEXICAL.
Y gets bound specially to 4 because Y is [pervasively]
proclaimed SPECIAL.
Reference style for name X is changed to SPECIAL, making
lexical X=3 invisible.
Reference style for name Y is changed to LEXICAL, making
dynamic Y=4 invisible.
Global X=1 and global Y=2 are first two elements of list.
X gets bound lexically to 5 because X is [pervasively]
proclaimed LEXICAL.
Y gets bound specially to 6 because Y is [pervasively]
proclaimed SPECIAL.
Closure is returned, capturing [lexical] X=5 but not
[special] Y=6.
Dynamic binding of Y to 6 disappears, dynamic binding
of Y to 4 reverts.
Closure is funcalled, returning captured X=5 and dynamically
active Y=4 in a list which becomes third list element.
Rationale:
This mechanism provides a simple and straightforward answer to
the problems stated above.
Current Practice:
Probably no one implements this.
Cost to Implementors:
A fair amount compiler work would probably be needed. Some compilers
may have hooks for most of this already laying around, but some may not.
Note well that this proposal does not require separate global lexical
and dynamic cells, so the data storage layout of Lisp need not change.
Moon says...
I have now thought of an efficient way to do this on Lisp machines,
using invisible pointers, and another efficient way to do it on
stock hardware, using one extra instruction on every global
reference of one or the other sort, plus a few extra instructions
in SPECIAL binding and unbinding. Given that, I no longer object
to the proposal as unimplementable.
It doesn't just require a few compiler changes, it requires some
reimplementation of the representation of global variables, with
concomitant changes to the compiler, the loader, the interpreter,
and probably the debugger. Every symbol now potentially has two
values accessible from the interpreter (the current SPECIAL and
the global LEXICAL) and you need the corresponding new data
structure to keep track of that.
Rees suggests...
In shallow-bound implementations, implementors may have to add a
small run-time routine that searches the dynamic saved-binding
stack to look for the global value in the case where the variable
has been dynamically bound. One might want a bit (or a count)
somewhere (perhaps in the symbol itself) to speed up the common
case of access to a global binding of a variable that hasn't been
dynamically bound; without some kind of optimization, you have to
search the whole saved-binding stack on every reference to a
free [lexical] variable.
While naively you might think you'd incur the cost of clearing the
valid bit on every dynamic binding (not acceptable), in actuality
the bit is a static property of programs (PROGV excepted). So the
only places you ever need to clear FOO's valid bit are in PROGV,
in the interpreter, and when FASLOADing code that contains a compiled
dynamic binding of FOO.
Cost to Users:
For the most part, this change is upward compatible.
Some code-walking tools would have to change.
Cost of Non-Adoption:
It would continue to be difficult to share code with Scheme.
New CL users coming from the Scheme community would be confused by
their sometimes inability to map what they know about variable binding
into the CL model of variable binding.
Some interesting native CL applications would be impossible to write
in a syntactically convenient style.
Benefits:
Enhanced flexibility of expression.
Rationalization of the semantics of dynamic variables.
Aesthetics:
Improved appeal to a certain sector of the programming community.
Discussion:
Rees points that it is an oversimplification to describe Scheme's
binding simply as LG since they have no Dynamic environment and
there is no way to distinguish LG and LDG. However, the reasons he
prefers LG are:
1. It's nice for readability and understandability to have a
declaration which tells you that a variable will not be
dynamically bound.
2. It's nice for performance in deep-bound implementations to have a
declaration that says that no search will be needed.
Of course, he notes, there could be a counter-argument to item 2
(in favor of LDG) in order to prefer shallow bound implementations,
but that still would not defeat the argument in item 1. Rees believes
that LG is slightly preferrable, but that LDG would be essentially
adequate for most of his needs.
Pitman supports PROCLAIM-LEXICAL:LG and believes that giving LDG the
name LEXICAL would be a serious mistake, leaving open the door for
program bugs due to accidental binding of variables presumed by the
programmer not to be bound. If someone (Moon?) seriously wanted LDG
type variables in addition to LG variables (under a name other than
LEXICAL), Pitman would not object.
Dalton expressed support for PROCLAIM-LEXICAL:LG (Version 6).
He observes that another reason for opposing LDG is that it suggests
the possibility that someone might want DLG. LG is simpler and still
accomplishes the stated purpose. He adds ``I would like to be able
to explain the global environment as a sort of giant, extensible
LET abound everything. This proposal seems to get fairly close.''
It would be possible to submit a proposal for a GLOBAL (G) declaration
under separate cover if anyone (Xerox?) was interested. Pitman thinks
this would be an interesting idea. Dalton points out, however, that
already with this proposal there is enough power to at least deal with
globals -- albeit circuitously. For example, to reference a global
variable X, one could write subroutines such as:
(defun global-x () (declare (lexical x)) x)
(defun set-global-x (value) (declare (lexical x)) (setq x value))
Eg, consider:
(defun f (x) (+ (global-x) x))
In principle, we could imaging saying that free variables should be
lexical by default, but that would only reduce error checking to no
good end. To be really useful, this proposal will need to be followed
by a proposal for primitives analogous to DEFVAR and/or DEFPARAMETER
but for lexical variables. However, since arguments over syntax are
likely to have plenty of issues of their own, we've separated this
proposal for primitive functionality from issues of syntax which
can be dealt with separately once this is passed.
Moon expressed concerns about the efficiency issues but after
thinking about it for a while convinced himself that this is
efficiently implementable both on stock and special purpose hardware.
JonL expressed concerns about the last-minute nature of this change,
which he sees as untested. This concern applies to the mixin of
the dynamic environment implicit in the LDG proposal.
Dalton suggests that an alternative solution to the speed issue
might be possible to obtain by restricting a particular variable to
be either LEXICAL or SPECIAL but not both.
Dalton points that even if people don't like the details here, there
must be a better fallback solution than "do nothing". Pitman agrees
heartily.